Navigation devices

ABSTRACT

A method of creating map data including search acceleration data arranged to increase the speed at which a route can be planned across an electronic map comprising a plurality of navigable segments, each navigable segment representing a segment of a navigable route in the area covered by the map, wherein the method comprises:
         a) reducing the number of navigable segments to be considered in the creation of the search acceleration data by removing navigable segments to form a core network of navigable segments;   b) dividing the electronic map into a set of hierarchical regions such that the or each navigable segment is categorized into at least one region in each level of the hierarchy;   c) using a time varying function associated with at least some, and generally each, navigable segment of the core network to determine whether that navigable segment is part of minimum cost route to at least one of the regions and recording this determination in the search acceleration data.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 13/706,379, filed on Dec. 6, 2012, which is a continuationapplication of U.S. patent application Ser. No. 13/382,949 filed Jan. 9,2012, now abandoned, and which is the National Stage of InternationalApplication No. PCT/EP2010/059947 filed on Jul. 9, 2010, and designatingthe United States, which claims benefit to U.S. Provisional PatentApplication Serial No. 61/213,746 filed on Jul. 9, 2009. The entirecontent of these applications is incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to a computerised method of generating mapdata and related systems. In particular, but not exclusively, the methodof generating the map data is used to facilitate route planning betweenat least two points according to a predetermined cost function.Embodiments of the invention may generate search acceleration datawhich, when used in route planning, reduce the time taken to generate aroute.

BACKGROUND OF THE INVENTION

Route planning devices (often referred to as Satellite Nav.'s, PortableNavigation Devices (PND's) or similar) together with web sitesaccessible across the World Wide Web (WWW) such ashttp://routes.tomtom.com/ are well known and allow a user thereof toplan a route between two points. Such technology may be referred togenerically as electronic route planning or just route planning.

Map data for such electronic route planning comes from specialist mapvendors such as Tele Atlas NV. When performed on a PND such routeplanning typically uses location data from a GPS system. However, otherapplications may allow a user to input his/her location or other pointto be considered for routing planning purposes.

Such map data comprises a plurality of roads (and other navigable paths)which can be described as lines—i.e. vectors or road segments (e.g.start point, end point, direction for a road, with an entire road beingmade up of many hundreds of such segments, each uniquely defined bystart point/end point direction parameters). A map is then a set of suchroad vectors, data associated with each vector (speed limit; traveldirection, etc.) plus points of interest (POIs), plus road names, plusother geographic features like park boundaries, river boundaries, etc.,all of which are defined in terms of vectors. All map features (e.g.road vectors, POIs etc.) are typically defined in a co-ordinate systemthat corresponds with or relates to the GPS co-ordinate system, enablinga device's position as determined through a GPS system to be locatedonto the relevant road shown in a map and for an optimal route to beplanned to a destination.

Such map data can be extensive. It is known for maps to cover areashaving in excess of 120,000,000 vectors and an example of such map datawould be a map covering the area of Europe and Russia. As such, planninga route using such map data is complex and can be time consuming. Also,it is known that such route planning is a trade-off between accuracy andtime.

Prior art which has considered ideas at improving the speed at whichrouting can occur includes U.S. Pat. No. 6,636,800 which discussesrefinements to the A* best-first search strategy suitable for muchsmaller map sizes such as the highway road network of Western Europe(having roughly 400,000 vectors).

SUMMARY OF THE INVENTION

According to a first aspect of the invention there is provided a methodof creating map data including search acceleration data arranged toincrease the speed at which a route can be planned across an electronicmap comprising a plurality of navigable segments, each navigable segmentrepresenting a segment of a navigable route in the area covered by themap, wherein the method comprises:

-   -   a) reducing the number of navigable segments to be considered in        the creation of the search acceleration data by removing        navigable segments to form a core network of navigable segments;    -   b) dividing the electronic map into a set of hierarchical        regions such that the or each navigable segment is categorized        into at least one region in each level of the hierarchy;    -   c) using a time varying function associated with at least some,        and generally each, navigable segment of the core network to        determine whether that navigable segment is part of minimum cost        route to at least one of the regions and recording this        determination in the search acceleration data; and    -   d) generating the map data.

Such a method is believed advantageous because it allows the searchacceleration data to be calculated quicker than prior art methods. Inturn, the search acceleration data is believed advantageous since itallows route planning using that map data to be performed quicker.

Typically the search acceleration data is calculated as a plurality ofbit vectors. Some embodiments of the invention may calculate mayindicate via a bit of the search acceleration data whether or not a roadsegment is part of a minimum cost route from an origin navigable segmentto a destination region.

The skilled person will appreciate that generally each navigablesegment, or may be node, within the map data has associated therewiththe time varying function. For example, the time varying function maycomprise the average speed on the navigable segment at various timeintervals. For example, the average speed may be specified at 5 minuteintervals or the like.

Conveniently, the core network is generated by removing navigablesegments for which the search acceleration data can later be recovered.Such a method is advantageous since it allows search acceleration datato be determined for substantially all navigable segments within theelectronic map thereby route planning to be accelerated from anynavigable segment within the map.

Some embodiments of the invention may utilize any one or more of thefollowing techniques to remove navigable segments from the electronicmap prior to the creation of the search acceleration data:

-   -   fulfil a predetermined criterion related to the road property;    -   removing navigable segments from the network which form parts of        the network that are sufficiently small according to some        predetermined criterion and that could be disconnected from the        rest of the network by removing a set of navigable segments that        fulfils some further predetermined criterion;    -   collapsing nodes, which occur at junctions between navigable        segments, onto one another in predetermined situations; and    -   collapsing nodes onto one another if they have two or less than        two navigable segments connected thereto.

Such techniques are believed advantageous since they reduce the numberof navigable segments that need to be considered during the generationof the search acceleration data which increases, perhaps significantly,the speed at which the search acceleration data can be created.

Additionally, or alternatively, embodiments of the invention may utilizeany one or more of the following techniques to compress the searchacceleration data once it has been created:

-   -   Computing the correlation of pairs of bits in the search        acceleration data;    -   Coalescing substantially correlated bits in the search        acceleration data in order to reduce the number of bits to        encode in a lossless manner;    -   Coalescing correlated bits in the search acceleration data in        order to perform lossy compression;    -   Re-ordering bits in coalesced search acceleration data according        to their correlations;    -   Huffman encoding the search acceleration data;

In some embodiments the substantially correlated bits may be thought ofas almost correlated with one another; i.e. there may small differencessearch acceleration data which is to be compressed. The closeness of thesearch acceleration data at which point they are coalesced may betunable according to a predetermined criterion. Thus, embodiments of theinvention that implement such lossy coalescing further reduce the memoryfootprint occupied by the search acceleration data at the expense ofincreasing the processing required to perform route planning using thesearch acceleration data.

Embodiments of which re-order search acceleration data are advantageousbecause he efficiency at which Huffman compression can compress thesearch acceleration data can be increased.

According to a second aspect of the invention there is provided a methodof creating map data, including search acceleration data arranged toincrease the speed at which a route can be planned across an electronicmap, the method comprising using at least one processing apparatus toprocess the electronic map which comprises a plurality of navigablesegments, representing segments of a navigable route in the area coveredby the map, comprising causing the processing apparatus to:

-   -   a. process the navigable segments in order reduce the number of        navigable segments to be considered in the creation of the        search acceleration data by removing navigable segments to form        a core network of navigable segments;    -   b. generate the search acceleration data for at least some of,        and generally each of, the navigable segments of the core        network indicating whether that navigable segment is part of a        minimum cost route; and    -   wherein step a. includes any one or more of the following:        -   fulfil a predetermined criterion related to the road            property;        -   removing navigable segments from the network which form            parts of the network that are sufficiently small according            to some predetermined criterion and that could be            disconnected from the rest of the network by removing a set            of navigable segments that fulfils some further            predetermined criterion;        -   collapsing nodes, which occur at junctions between navigable            segments, onto one another in predetermined situations; and        -   collapsing nodes onto one another if they have two or less            than two navigable segments connected thereto.

According to a third aspect of the invention there is provided a methodof creating map data, including search acceleration data arranged toincrease the speed at which a route can be planned across an electronicmap, the method comprising using at least one processing apparatus toprocess an electronic map which a plurality of navigable segments eachhaving a plurality of nodes associated therewith, representing segmentsof a navigable route in the area covered by the map and having at leastone attribute associated therewith representing a parameter of thenavigable route, the method comprising:

-   -   a) assessing the at least one attribute;    -   b) dividing the electronic map into a set of hierarchical        regions such that the or each navigable segment is categorized        into at least one region in each level of the hierarchy, wherein        the categorization uses the assessment of step a. to ensure that        the nodes associated with the navigable segments are balanced        across the regions of the electronic map;    -   c) generating the map data.

An advantage of such a method is that it can help to balance the numberof navigable segments that are distributed between each of the regionswhich can in turn help to increase the effectiveness of the searchacceleration data.

Steps a) and b) may be performed iteratively until a predeterminedcriterion measuring the balance of the nodes across the regions is met.For example, an upper threshold on the number of navigable segments thatmay occur in a given region may be such a criterion. Such a measure canhelp to ensure that the search acceleration data is calculated quicker;if the regions contain imbalances in the navigable segments containedtherein then the speed at which the search acceleration data can becalculated may be compromised.

The attribute may include any of the following:

-   -   the type of navigable segment;    -   the average speed along the navigable segment;    -   the length of the navigable segment;    -   the connectivity of that segment to other navigable segments.

The method may be arranged to determine regions of the map to whichjourney times would be slower than a predetermined threshold and mayfurther separate navigable segments within those regions from otherregions of the electronic map.

The method may be arranged to separate navigable segments which are partof islands from other regions of the electronic map, which may beperformed by determining that attribute for that navigable segment is aferry line. Such a method is advantageous since travel to such islandscan be slower than to other regions of the electronic map and inclusionof such islands may compromise the effectiveness of the searchacceleration data and/or may slow down the calculation of the searchacceleration data.

According to a fourth aspect of the invention there is provided a methodof creating map data, including search acceleration data arranged toincrease the speed at which a route can be planned across an electronicmap, the method comprising using at least one processing apparatus toprocess an electronic map comprising a plurality of navigable segmentseach representing segments of a navigable route in the area covered bythe map, the method comprising:

-   -   a) dividing the map into a plurality of hierarchical regions        belonging to at least a coarser level and a neighboring finer        level such that each navigable segment is categorized into at        least one region in each of the coarser and finer levels and        wherein any one region of the coarser level contains a plurality        of regions of the finer level;    -   b) determining, for a given destination region, the extent of a        visibility area, comprising at least the coarser level region        containing the destination region, by assessing whether regions        close to the coarser level region containing the destination        region should be added to the visibility area and adding those        regions if the assessment is positive;    -   c) calculating, for at least some navigable segments,        information on at least one minimum cost route to that        destination region;    -   d) wherein the processing of a navigation segment includes the        performance of a reverse search from the destination region back        toward the navigable segment and includes substantially only        navigable segments in the visibility area of the destination        region; and    -   e) generating the map data.

An advantage of such a method is that the use of the vicinity areaallows the search space, used to generate the search acceleration data,is constrained and as such the speed at which the search accelerationdata can be created is increased.

According to a fifth aspect of the invention there is provided a methodof creating map data, including search acceleration data arranged toincrease the speed at which a route can be planned across an electronicmap, the method comprising using at least one processing apparatus toprocess an electronic map comprising a plurality of navigable segmentseach representing segments of a navigable route in the area covered bythe map, the method comprising:

-   -   a) dividing the map into a plurality of hierarchical regions        belonging to at least a coarser level and a neighboring finer        level such that each navigable segment is categorized into at        least one region in each of the coarser and finer levels and        wherein any one region of the coarser level contains a plurality        of regions of the finer level;    -   b) determining, for a given destination region, the extent of a        visibility area, comprising at least the coarser level region        containing the destination region, by assessing whether regions        close to the coarser level region containing the destination        region should be added to the visibility area and adding those        regions if the assessment is positive;    -   c) calculating, for at least some navigable segments information        on at least one minimum cost route to that destination region;    -   d) arranging the search acceleration data to comprise        information on the at least one minimum cost route to the        destination region for at least some and typically each        navigable segment in the visibility area; and    -   e) generating the map data.

An advantage of such a method is that the speed at which route planningusing the search acceleration data can be performed can be increased.The search acceleration data may be thought of as a sign post to thedestination region. Thereby increasing the number of regions thatcontain search acceleration data to regions contained within thevicinity area increases the number of regions that contain ‘sign posts’to the destination region. Therefore, the time to generate the searchacceleration data may be increased although the performance of the routeplanning using the search acceleration data will also be increased.

The assessment as to whether regions are close to the coarser levelregion containing the destination region may be based upon apredetermined criterion. This predetermined criterion may be any one orcombination of the following: graph-theoretical distance, geographicaldistance, travel time, fuel consumption and/or CO2 emission. Indeed, insome embodiments closer may be determined to be regions which areadjacent to the coarser level region containing the destination region.

Regions added to the visibility area may comprise at least one of thefollowing: one or more regions of the coarser level and a portion of oneor more regions of the coarser level.

Any of the above methods may include within the search acceleration dataat least one additional route in addition to the minimum cost routewherein the additional route may reflect any one or more of thefollowing:

-   -   different minimum cost routes at different times between a given        departure and destination point;    -   different minimum cost routes between a given departure and        destination point for different traffic situations;    -   different minimum cost routes between a given departure and        destination point according to different cost function;    -   different minimum cost routes between a given departure and        destination point for any dynamic changes in a given road        network;    -   alternative routes between a given departure and destination        point according to the same cost function; and    -   different destination points in a similar direction to one        another.

As such, the search acceleration data may include a plurality of‘minimum cost’ routes each of which is generally judged against adifferent criterion. An advantage of such a method is that routeplanning using the minimum cost data may generate optimum routes for avariety of criterion.

According to a sixth aspect of the invention there is provided a

-   -   a) dividing the map into a plurality of hierarchical regions at        one or more levels of hierarchy;    -   b) processing at least some of the regions belonging to a        particular level of hierarchy in the order of the level        hierarchy, working from the finest level up to the coarsest, and        for at least some of these regions, determining which navigable        segments enter and/or leave that region;    -   c) processing at least some of the navigable segments within the        map to determine at least one minimum cost route from that        navigable segment to a destination region;    -   d) wherein the processing of a navigable segment includes the        performance of a reverse search from the destination region back        toward the navigable segment;    -   e) in the resulting search graph, identifying, for at least one        region at the next-finer level, a set of regions at that        next-finer level, such that each minimum-cost paths from the        given region passes through at least one of the regions of the        set, resulting in a correlation matrix;    -   f) in the resulting search graph, identifying which navigable        segments are not contained in any path from a region different        from their own to a further destination region, so they can be        thought of as “non-transit segments”, and removing those        non-transit segments for the subsequent steps in order to reduce        the number of navigable segments which are considered in the        subsequent steps;    -   g) wherein the creation of search acceleration data comprises        using the correlation matrix to assign search acceleration data        to the non-transit segments which have been removed in all        previous steps;    -   h) generating map data

Any of the above aspects of the invention may use one or more navigationdevices to generate positioning data being constituted by at least aseries of positions. Latterly the methods may process the positioningdata to generate speed profiles therefrom which vary with respect totime, wherein the generated speed profiles are associated with thenavigable segment on which the positioning data generating that speedprofile occurred.

According to a seventh aspect of the invention there is provided anavigation device arranged to generate a route across an electronic mapusing a processor thereof, wherein the processor is arranged to:

-   -   perform a route search across the electronic map;    -   perform, in a cost calculation at nodes processed during the        search which represent navigable segments in the electronic map,        an assessment of whether navigable segments connected to those        nodes are marked as being part of a minimum cost route; and if        there are such navigable segments exploring only those navigable        segments.

The search may compromise a tree search such as A* search, any othersearch method described herein, or the like. In other embodiments, thesearch may comprise a directed acyclic graph search.

According to an eighth aspect of the invention there is provided amethod of generating a route across an electronic map comprisingperforming an A* search in a cost calculation performed at nodes of thegraph tree which represents a navigable segment within the electronicmap and including assessing search acceleration data to determinewhether navigable segments connected to that node are marked as beingpart of a minimum cost route and if there are such navigable segmentsexploring only those navigable segments.

The search acceleration data is conveniently pre-generated and storedwith or in association with the electronic map.

Such a method is thought to be advantageous since it may significantlyincrease the speed at which the route can be generated across theelectronic map.

According to a ninth aspect of the invention there is provided anavigation device arranged to generate a route across an electronic mapto a destination using a processor thereof to analyse map data, whereinthe processor is arranged to:

-   -   perform a route search across the electronic map using        information held in the map data;    -   perform, in a cost calculation at nodes processed during the        search which represent navigable segments in the electronic map,        an assessment of whether navigable segments connected to those        nodes are marked, within the search acceleration data, as being        part of a minimum cost route;    -   wherein said map data includes an indicator as to whether        additional search acceleration data is present from that node to        the destination, said additional search information providing        further information on minimum cost routes; and    -   if such minimum cost data is available, exploring only those        navigable segments having such search acceleration data.

Such a device is advantageous because the indicator provided in the mapdata helps to provide information which constrains the number of routeswhich are explored by the navigation device.

The indicator may comprise a visibility area of the destination and thenavigation device may be arranged to utilise the further information onminimum cost routes when it is within visibility region.

According to further aspects of the invention there may be providedcomputing apparatus arranged to perform any of the above methods.

According to further aspects of the invention there are provided machinereadable mediums containing instructions to provide, when read onto atleast one machine, any of the methods above.

According to yet further aspects of the invention there are providedmachine readable mediums containing instructions to cause the or eachmachine onto which they are read to perform as the computing devices ofany of the above aspects of the invention.

In embodiments in which the method is performed in parallel instructionsmay be read onto a plurality of machines.

The skilled person will appreciate that features of many of the featuresof the above aspects of the invention may be applied mutatis mutandis toother of the aspects of the invention.

In any of the above aspects of the invention the machine readable mediummay comprise any of the following: a floppy disk, a CD ROM, a DVDROM/RAM (including a −R/−RW and +R/+RW), a hard drive, a memory(including a USB memory key, an SD card, a Memorystick™, a compact flashcard, or the like), a tape, any other form of magneto optical storage, atransmitted signal (including an Internet download, an FTP transfer,etc), a wire, or any other suitable medium.

The skilled person will appreciate that many of the methods and/orapparatus described herein may be performed in software, hardware orfirmware. Indeed, a combination of these three may be suitable for atleast some of the ideas.

Reference to generation of map data in any of the above aspects of theinvention may in fact be an optional step and the skilled person willappreciate that such a step may well be optional to that method.

According to yet a further aspect of the invention there is provided amethod of generating search acceleration data comprising pre-processingnavigable segments to generate that data.

According to a further aspect of the invention there is provided amethod of generating map data from positioning data, the methodcomprising using at least one processing apparatus to process anelectronic map comprising a plurality of navigable segments,representing segments of a navigable route in an area covered by themap, the method comprising:

-   -   1. using one or more navigation devices to generate positioning        data being constituted by at least a series of positions;    -   2. processing the positioning data to generate speed profiles        therefrom which vary with respect to time, wherein the generated        speed profiles are associated with the navigable segment on        which the positioning data generating that speed profile        occurred;    -   3. generating, for at least some of the navigable segments,        search acceleration data where the search acceleration data        indicates for at least one, and typically each of the regions,        whether that navigable segment comprises part of a route to        minimize a cost for a predetermined criterion to travel to the        or each region, wherein the generation uses a time varying        function for the predetermined criterion; and    -   4. generating map data.

In aspects of this invention, reference to a node, line or road may betaken to be a reference to a navigable segment and vice-versa and theskilled person will appreciate how to make the necessary changes.

BRIEF DESCRIPTION OF THE FIGURES

There now follows by way of example only a detailed description ofembodiments of the present invention with reference to the accompanyingdrawings in which:

FIG. 1 is a schematic illustration of an exemplary part of a GlobalPositioning System (GPS) usable by a navigation device;

FIG. 1a is a schematic illustration of electronic components of aPortable Navigation Device (PND) or any other suitable navigationdevice;

FIG. 1b is a schematic diagram of an arrangement of mounting and/ordocking a navigation device;

FIG. 1c is a schematic representation of an architectural stack employedby the navigation device of FIG. 1 a;

FIG. 2 shows a portion of an example map as generated by embodiments ofthe invention;

FIG. 3 shows the map of FIG. 2 on which nodes used for routing areshown;

FIG. 4 shows the map of FIG. 2 following processing;

FIG. 5 shows an example of how nodes, in some embodiments, are allocatedto the map of FIG. 3;

FIG. 6 illustrates an example of how a map may be partitioned into aplurality of nested regions;

FIG. 6a illustrates an enhancement of the partitioning of FIG. 6;

FIG. 7 shows an example set of bit vectors utilised by embodiments ofthe invention;

FIG. 7a illustrates how time profiled information is utilised during aDijkstra exploration of a network;

FIG. 8 shows an example file format for a file of an embodiment of theinvention;

FIG. 9 shows an embodiment of how the region remap table and region IDlists of FIG. 8 may be encoded;

FIG. 10 shows an example file format for the coarsest nested region asillustrated in FIG. 6;

FIG. 11 shows an example file format for nested regions other than thecoarsest;

FIG. 12 exemplifies coalescence of bits within an encoding scheme;

FIGS. 13a and 13b exemplify the effect of coalescing bits;

FIG. 14 also exemplifies the effect of coalescing bits;

FIG. 15 shows a map highlighting routes considered using PRIOR ARTrouting techniques;

FIG. 16 shows a map highlighting routes considered by embodiments of thecurrent invention;

FIG. 17 shows an example of the A* search method (PRIOR ART);

FIG. 18 shows a modification to FIG. 17 used by at least someembodiments of the invention;

FIG. 19 shows a flow chart outlining steps of the method; and

DETAILED DESCRIPTION OF THE FIGURES

Throughout the following description the same reference numerals will beused to identify like parts. Throughout the description of the variousembodiments reference is made to the flow chart of FIG. 19 which hasreference numerals in the 19xx series.

FIG. 1 schematically shows a Global Positioning System (GPS) which is asatellite-radio based navigation system which may be utilised todetermine continuous position, velocity, time, and in some instancesdirection information for an unlimited number of users. Formerly knownas NAVSTAR, the GPS incorporates a plurality of satellites which orbitthe earth in extremely precise orbits. Based on these precise orbits,GPS satellites can relay their location, as GPS data, to any number ofreceiving units. However, it will be understood that Global Positioningsystems could be used, such as GLOSNASS, the European Galileopositioning system, COMPASS positioning system or IRNSS (Indian RegionalNavigational Satellite System).

The GPS system is implemented when a device, specially equipped toreceive GPS data, begins scanning radio frequencies for GPS satellitesignals. Upon receiving a radio signal from a GPS satellite, the devicedetermines the precise location of that satellite via one of a pluralityof different conventional methods. The device will continue scanning, inmost instances, for signals until it has acquired at least threedifferent satellite signals (noting that position is not normally, butcan be determined, with only two signals using other triangulationtechniques). Implementing geometric triangulation, the receiver utilizesthe three known positions to determine its own two-dimensional positionrelative to the satellites. This can be done in a known manner.Additionally, acquiring a fourth satellite signal allows the receivingdevice to calculate its three dimensional position by the samegeometrical calculation in a known manner. The position and velocitydata can be updated in real time on a continuous basis by an unlimitednumber of users.

As shown in FIG. 1, the GPS system 100 comprises a plurality ofsatellites 102 orbiting about the earth 104. A GPS receiver 106 receivesGPS data as spread spectrum GPS satellite data signals 108 from a numberof the plurality of satellites 102. The spread spectrum data signals 108are continuously transmitted from each satellite 102, the spreadspectrum data signals 108 transmitted each comprise a data streamincluding information identifying a particular satellite 102 from whichthe data stream originates. The GPS receiver 106 generally requiresspread spectrum data signals 108 from at least three satellites 102 inorder to be able to calculate a two-dimensional position. Receipt of afourth spread spectrum data signal enables the GPS receiver 106 tocalculate, using a known technique, a three-dimensional position.

Thus, a GPS system allows a user of a device having a GPS receiver 106to determine his/her position on the planet earth to within a fewmetres. In order to make use of this information it has become commonpractice to rely on electronic maps which allow the user's position tobe shown thereon. Such maps are exemplified by providers such asTeleAtlas (http://www.teleatlas.com).

Not only do such electronic maps allow a user's position to be shownthereon using a GPS system (or by other means) but they allow a user toplan routes for journeys and the like (routing purposes). In order forthis route planning to occur, the electronic map is processed by anavigation device, which may be provided by a general computing device.

Specific examples of a navigation device include Satellite navigationdevices (Sat. Nav) which are convenient to refer to as PortableNavigation Devices (PNDs). It should be remembered, however, that theteachings of the present invention are not limited to PNDs but areinstead universally applicable to any type of processing device that isconfigured to process electronic maps, generally so as to provide routeplanning and navigation functionality. It follows therefore that in thecontext of the present application, a navigation device is intended toinclude (without limitation) any type of route planning and navigationdevice, irrespective of whether that device is embodied as a PND, avehicle such as an automobile, a portable computing resource, forexample a portable personal computer (PC), a mobile telephone or aPersonal Digital Assistant (PDA) executing route planning and navigationsoftware or a server, or other computing device, providing suchfunctionality across a network.

An example of such a navigation device in the form of a PND is shown inFIG. 1a and it should be noted that the block diagram of the navigationdevice 200 is not inclusive of all components of the navigation device,but is only representative of many example components. The navigationdevice 200 is located within a housing (not shown). The navigationdevice 200 includes processing circuitry comprising, for example, theprocessor 202 mentioned above, the processor 202 being coupled to aninput device 204 and a display device, for example a display screen 206.Although reference is made here to the input device 204 in the singular,the skilled person should appreciate that the input device 204represents any number of input devices, including a keyboard device,voice input device, touch panel and/or any other known input deviceutilised to input information. Likewise, the display screen 206 caninclude any type of display screen such as a Liquid Crystal Display(LCD), for example.

In the navigation device 200, the processor 202 is operatively connectedto and capable of receiving input information from input device 204 viaa connection 210, and operatively connected to at least one of thedisplay screen 206 and the output device 208, via respective outputconnections 212, to output information thereto. The navigation device200 may include an output device 208, for example an audible outputdevice (e.g. a loudspeaker). As the output device 208 can produceaudible information for a user of the navigation device 200, it shouldequally be understood that input device 204 can include a microphone andsoftware for receiving input voice commands as well. Further, thenavigation device 200 can also include any additional input device 204and/or any additional output device, such as audio input/output devicesfor example.

The processor 202 is operatively connected to memory 214 via connection216 and is further adapted to receive/send information from/toinput/output (I/O) ports 218 via connection 220, wherein the I/O port218 is connectible to an I/O device 222 external to the navigationdevice 200. The external I/O device 222 may include, but is not limitedto an external listening device, such as an earpiece for example. Theconnection to I/O device 222 can further be a wired or wirelessconnection to any other external device such as a car stereo unit forhands-free operation and/or for voice activated operation for example,for connection to an earpiece or headphones, and/or for connection to amobile telephone for example, wherein the mobile telephone connectioncan be used to establish a data connection between the navigation device200 and the Internet or any other network for example, and/or toestablish a connection to a server via the Internet or some othernetwork for example.

The memory 214 of the navigation device 200 comprises a portion ofnon-volatile memory (for example to store program code) and a portion ofvolatile memory (for example to store data as the program code isexecuted). The navigation device also comprises a port 228, whichcommunicates with the processor 202 via connection 230, to allow aremovable memory card (commonly referred to as a card) to be added tothe device 200. In the embodiment being described the port is arrangedto allow an SD (Secure Digital) card to be added. In other embodiments,the port may allow other formats of memory to be connected (such asCompact Flash (CF) cards, Memory Sticks™, xD memory cards, USB(Universal Serial Bus) Flash drives, MMC (MultiMedia) cards, SmartMediacards, Microdrives, or the like).

FIG. 1a further illustrates an operative connection between theprocessor 202 and an antenna/receiver 224 via connection 226, whereinthe antenna/receiver 224 can be a GPS antenna/receiver for example andas such would function as the GPS receiver 106 of FIG. 1. It should beunderstood that the antenna and receiver designated by reference numeral224 are combined schematically for illustration, but that the antennaand receiver may be separately located components, and that the antennamay be a GPS patch antenna or helical antenna for example.

In addition, the portable or handheld navigation device 200 of FIG. 3can be connected or “docked” in a known manner to a vehicle such as abicycle, a motorbike, a car or a boat for example. Such a navigationdevice 200 is then removable from the docked location for portable orhandheld navigation use. Indeed, in other embodiments, the device 200may be arranged to be handheld to allow for navigation of a user.

Referring to FIG. 1b , the navigation device 200 may be a unit thatincludes the integrated input and display device 206 and the othercomponents of FIG. 3 (including, but not limited to, the internal GPSreceiver 224, the processor 202, a power supply (not shown), memorysystems 214, etc.).

The navigation device 200 may sit on an arm 252, which itself may besecured to a vehicle dashboard/window/etc. using a suction cup 254. Thisarm 252 is one example of a docking station to which the navigationdevice 200 can be docked. The navigation device 200 can be docked orotherwise connected to the arm 252 of the docking station by snapconnecting the navigation device 200 to the arm 252 for example. Thenavigation device 200 may then be rotatable on the arm 252. To releasethe connection between the navigation device 200 and the dockingstation, a button (not shown) on the navigation device 200 may bepressed, for example. Other equally suitable arrangements for couplingand decoupling the navigation device 200 to a docking station are wellknown to persons of ordinary skill in the art.

Turning to FIG. 1c , the processor 202 and memory 214 cooperate tosupport a BIOS (Basic Input/Output System) 282 that functions as aninterface between functional hardware components 280 of the navigationdevice 200 and the software executed by the device. The processor 202then loads an operating system 284 from the memory 214, which providesan environment in which application software 286 (implementing some orall of the described route planning and navigation functionality) canrun. The application software 286 provides an operational environmentincluding the Graphical User Interface (GUI) that supports corefunctions of the navigation device, for example map viewing, routeplanning, navigation functions and any other functions associatedtherewith. In this respect, part of the application software 286comprises a view generation module 288.

In the embodiment being described, the processor 202 of the navigationdevice is programmed to receive GPS data received by the antenna 224and, from time to time, to store that GPS data, together with a timestamp of when the GPS data was received, within the memory 214 to buildup a series of positions of the navigation device. Each data recordso-stored may be thought of as a GPS fix; i.e. it is a fix of thelocation of the navigation device and comprises a latitude, a longitude,a time stamp and an accuracy report. This series of positions may bethought of as positioning data.

In one embodiment the data is stored substantially on a periodic basiswhich is for example every 5 seconds. The skilled person will appreciatethat other periods would be possible and that there is a balance betweendata resolution and memory capacity; i.e. as the resolution of the datais increased by taking more samples, more memory is required to hold thedata. However, in other embodiments, the resolution might besubstantially every: 1 second, 10 seconds, 15 seconds, 20 seconds, 30seconds, 45 seconds, 1 minute, 2.5 minutes (or indeed, any period inbetween these periods). Thus, within the memory of the device there isbuilt up a record of the whereabouts of the device 200 at points intime.

In some embodiments, it may be found that the quality of the captureddata reduces as the period increases and whilst the degree ofdegradation will at least in part be dependent upon the speed at whichthe navigation device 200 was moving a period of roughly 15 seconds mayprovide a suitable upper limit.

Further, the processor 202 is arranged, from time to time, to upload therecord of the whereabouts of the device 200 (i.e. the GPS data and thetime stamp) to a server. In some embodiments in which the navigationdevice 200 has a permanent, or at least generally present, communicationchannel connecting it to the server the uploading of the data occurs ona periodic basis which may for example be once every 24 hours. Theskilled person will appreciate that other periods are possible and maybe substantially any of the following periods: 15 minutes, 30 minutes,hourly, every 2 hours, every 5 hours, every 12 hours, every 2 days,weekly, or any time in between these. Indeed, in such embodiments theprocessor 202 may be arranged to upload the record of the whereabouts ona substantially real time basis, although this may inevitably mean thatdata is in fact transmitted from time to time with a relatively shortperiod between the transmissions and as such may be more correctlythought of as being pseudo real time. In such pseudo real timeembodiments, the navigation device may be arranged to buffer the GPSfixes within the memory 214 and/or on a card inserted in the port 228and to transmit these when a predetermined number have been stored. Thispredetermined number may be on the order of 20, 36, 100, 200 or anynumber in between. The skilled person will appreciate that thepredetermined number is in part governed by the size of the memory214/card within the port 228.

In other embodiments, which do not have a generally presentcommunication channel the processor may be arranged to upload the recordto the server when a communication channel is created. This may forexample, be when the navigation device 200 is connected to a user'scomputer. Again, in such embodiments, the navigation device may bearranged to buffer the GPS fixes within the memory 214 or on a cardinserted in the port 228. Should the memory 214 or card inserted in theport 228 become full of GPS fixes the navigation device may be arrangedto deleted the oldest GPS fixes and as such it may be thought of as aFirst in First Out (FIFO) buffer.

In the embodiment being described, the record of the whereaboutscomprises one or more traces with each trace representing the movementof that navigation device 200 within a 24 hour period. Each 24 hourperiod is arranged to coincide with a calendar day but in otherembodiments, this need not be the case.

The server is arranged to receive the record of the whereabouts of thedevice and to store this within a mass data storage for processing.Thus, as time passes the mass data storage accumulates a plurality ofrecords of the whereabouts of navigation devices 200 which have uploadeddata. Generally, the server will collect the whereabouts of a pluralityof navigation devices 200.

The server may then be arranged to generate speed data from thecollected whereabouts of the or each device. This speed data maycomprise s time varying speed profile showing how the average speedalong navigable segments of a map vary with time.

FIG. 2 shows an example of an electronic map which, in the embodimentbeing described, is viewed on a navigation device across a network whichin this case is the Internet. A first step in any of the embodimentsbeing described herein is generation of such an electronic map 1900. Themap may be viewed at: http://routes.tomtom.com/

In order for the electronic map of FIG. 2 to be used for routingpurposes to occur it has a series of nodes therein which are nottypically seen by a user of the electronic map. As such, the nodes, etc.may typically be referred to as map data. However, some of the nodes 300are shown in FIG. 3 for ease of understanding. These nodes are providedat intersections, end regions of roads, etc. and are used for routingpurposes. When a user asks his/her navigation device to plan a routebetween two or more points the navigation device will generally plan theroute between the relevant nodes of the map (although it is possible toplan a route to a group of nodes). As such, the map data can be used togenerate a route according to at least one criterion set by a user ofthe navigation device.

The skilled person will appreciate that the electronic map alsocomprises further nodes which provide the shape of road segments, thelocation of entrances to buildings, etc.

Thus, each node 300 has at least a single, and generally a plurality, ofroad segments which a user may travel along emanating therefrom. Forexample, the node 302 has four such road segments 304 a,b,c,d. Each roadsegment may be thought of as a navigable segment since it may refer to aroute which is not a road such as a footpath, cycle path, canal, railwayline, track, or the like. For convenience however reference is made to aroad segment. Thus, the map as shown in FIG. 2 shows to a user thereof aplurality of road segments, each of which represents a portion of anavigable route in the area covered by the map.

Route planning methods (such as the Dijkstra method, A* method orMoore/Pape methods) are known. However, these can be prohibitively slowin terms of calculation times. An example of how the speed of such routeplanning may be increased is shown in U.S. Pat. No. 6,636,800, theteaching of which are hereby incorporated by reference.

Embodiments being described herein may generate, in a pre-processingstep, a so-called side-file containing search acceleration data which isused to accelerate generation of a route when processing the electronicmap. This information may be held as binary data in what may be termed abit-vector; i.e. a string of 0's and 1's (or a compressed encodingthereof). As such, the side-file may also be thought of as map data butthe side-file may be supplied with or without the electronic map (forexample, as shown in FIG. 2). Thus, some embodiments of the inventionmay provide the map data as a map separable from a side-file, whereasother embodiments of the invention may combine the map and side-filedata.

However, the skilled person will appreciate that if a side-file is usedthen it should be used with the electronic map for which the side-filewas generated. If this is not performed then it is conceivable thatincorrect routes will be obtained (eg routes which do not minimize thecost function set by a user thereof).

Also, different embodiments of the invention may specify differentparameters for the generation of the search acceleration data (which inthis embodiment are a series of bit vectors and will be convenientlyreferred to as bit vectors hereinafter). As such, if subsequent routeplanning using the generated map data uses different parameters to thoseused to create the bit vectors, the bit vectors are unlikely to beuseful for that route planning.

For example, some embodiments may generate bit vectors for travelthrough the map by car. If subsequent route planning is used to generatea route for walking then the car specific bit vectors are unlikely to beuseful. In another example, some embodiments may generate the bitvectors assuming that a user is happy to travel along a motorway, tollroad, etc. If, in subsequent route planning, a user requests a routewhich does not utilise motorways, toll roads, etc. then the bit vectorsare unlikely to be useful.

Some embodiments of the invention may generate a plurality of sets ofbit vectors each having a different set of predetermined criterion. Forexample, embodiments of the invention may generate roughly any of thefollowing: 2, 3, 4, 5, 6, 10, 15, or more sets of bit vectors.

Thus, in some embodiments and to generate the side-file, in a mappre-processing step the nodes are divided into a plurality of regionsand as such, any map is divided into a known number of regions—forexample N. This is explained in more detail hereinafter with referenceto FIG. 5. This pre-processing generates data which can be utilisedalong-side the map in order to increase the speed of the route planningmethods.

In an iterative process, which may be recursive, the nodes within themap data are divided into a set of hierarchical regions. Regions, asshown by the dotted lines in FIG. 5, are created each of which contain aplurality of nodes. The method moves those boundaries to include more orless nodes (and therefore navigable segments) and in moving thoseboundaries takes into consideration parameters of the road segmentsassociated with the nodes. Some embodiments of the method aim to set anupper limit on the number of nodes contained within any one region. Themethod may also determine membership of a region according to theexpected travel time along a navigable segment. For example, if anavigable segment has a slow average travel time (eg a ferry line) thenthose nodes may be moved to a separate region).

Typically the pre-processing is performed before the map data is usedregardless of whether the map data is to be used on a web site or on adevice such as a PND. As such, the pre-processing step is often referredto as a server side process.

Whilst any general computing device would be suitable for performing thepre-processing, the skilled person will appreciate that the higher theperformance of the apparatus, the faster the pre-processing will beperformed. Typically X86 architecture computing device will be utilisedfor the pre-processing. Such an X86 architecture device would typicallyrun an operating system (OS) such as Microsoft™ Windows™, UNIX, LINUX,OSX™ etc. However, other embodiments may use other computing platformssuch as a RISC architecture.

Also, as discussed elsewhere the pre-processing may be performed inparallel and as such may be performed on a plurality of computingdevices, or at least on a plurality of processor cores (which may bevirtual or real processor cores).

As a next pre-processing step, each road segment (eg 304 a-d) within aregion is processed to determine whether it is part of a least costroute to each of the number of regions (N) within the map and a bitvector is generated (the least cost assessment). Thus, the bit vector,for each road segment within a region, comprises a bit for eachnavigable segment within a region. That is the bit vector comprises N−1bits (1 for each region less the region in question) which are eitherset to 0 or 1 depending on whether that route forms part of the shortestroute to the region represented by the bit. Some embodiments, may addadditional bits to provide further information such as headers,visibility areas, and the like. These terms are described hereinafter.This is explained in more detail hereinafter with reference to FIG. 5.

The skilled person will appreciate that in this sense the least costroute can be determined against a number of different cost criteria. Forexample the least cost may be judged against any of the followingcriterion: shortest distance; shortest travel time; least expensive (interms of environmental impact); least petrol used; least CO₂ generated,etc. In the current embodiment the least cost is judged against theshortest travel time.

Thus, the skilled person will appreciate that for a map covering asignificant area N is likely to be large. Thus, the pre-processing cantake a significant amount of time.

Thus, in an example map, for example covering Europe and Russia theremight typically be 50,000,000 nodes having 120,000,000 road segments.Assume that there are 100 regions within the map then N equals 100 andthere are 120,000,000×100 (N) bits belonging to the bit vector; i.e.12×10⁹ bits are needed to store the 99 (i.e. N−1) bits for each roadsegment of the map. Using embodiments of the invention described below,such a map may use roughly 500 Mb of additional storage.

WO2009/053410 discusses a method which assigns speed profiles which givethe speed along a route of a map as a function of time. The contents ofthis application are hereby incorporated by reference. As such, and forrouting purposes, whether or not a route constitutes part of the fastestroute to another region will vary as a function of time. That is, as thetraffic density increases/decreases, for example in rush hours and thelike, it will become less/more desirable respectively to use a route.

Some embodiments may store a plurality of bit vectors for each roadsegment. The skilled person will appreciate that the higher theresolution at which the speed is recorded the higher the number of bitvectors required. However, other embodiments may make an assessment ofthe fastest route utilising a time varying function much as described inWO2009/053410.

When route planning across the electronic maps it is believed that it isnecessary to be able to do this using a time granularity of roughlycenti-second accuracy; that is to be able to specify the time ofdeparture from a node to an accuracy of 0.01 of a second in order tocorrectly determine the lowest cost route.

Thus, when considering this level of accuracy it will be appreciatedthat for the map considered above having 50,000,000 nodes and120,000,000 road segments has 120,000,000² possible routes therethrough.When the time dimension is further considered the number of possibleroutes is further increases: 7 (i.e. days per week)×24 (i.e. hours perday)×3600 (i.e. seconds per hour)×100 (i.e. cent-seconds persecond)×120,000,000²=870.912.000.000.000.000.000.000 (sextillion)possible routes. At current processing levels and using a naive approachin which each segment is explored at each time interval would takeapproximately 27,616,438,400,000,000 years. The map of Europe and Russiathat the applicant currently is growing year on year thereby increasingthis further.

Thus, it will be appreciated that a significant amount of data isrequired in order to store and process the data in the pre-processingstages.

As such, embodiments of the present invention use techniques in order tosignificantly reduce the amount of pre-processing. These techniques arenow described in more detail and some embodiments of the invention mayutilise all, whereas other embodiments may utilise only some of thetechniques.

Different embodiments of the invention may use different combinations ofthe features outlined below. As such, some embodiments may utilise allof the techniques described to reduce the amount of information. At theother extreme, other embodiments may utilise none of the techniques toreduce the data.

Some embodiments of the invention do not calculate bit vectors for roadsegments which do not meet predetermined criteria—as shown as step 1902(i.e. the road segments do not fulfil a predetermined criterion of theroad property). For example, road segments may not have bit vectorscalculated for them if it is not possible to travel along that roadsegment in a predetermined class of transport.

Thus, in an example where criterion of mode of transport is set to a carthe following road segments may not have bit vectors calculated forthem:

-   -   railways;    -   segments present in the map data which do not correspond to a        navigable segment;    -   one way road in wrong (illegal) direction;    -   road segments which are non-navigable by a form of transport (eg        pedestrian zones, footpaths, when considering driveability by        car);    -   road segments at a non-decision point (i.e. no turns away from        road segment);

Reduction of Network

One technique is to reduce the size of the network that is consideredfor the assessment as to whether road segments forms part of a leastcost route; reducing the number of road segments reduces the amount oftime it takes to make the calculation as shown at step 1904.

To illustrate this technique, the road network as shown in FIG. 2 isalso shown in FIG. 4 but with road segments which are not useful for theleast cost assessment deleted therefrom. This reduction of the networkaims to provide the smallest sub network on which the least costassessment should be made; thus the skilled person will appreciate thatnavigable segments have been removed to form a core network.

In mathematical terms the network that is left, and as illustrated inFIG. 4, can be described as the largest bi-connected component of theundirected representation of the largest strong component of the roadnetwork of FIG. 2. The core network is determined by applying standardtechniques for both strong-connectivity (also known as bi-connectivity)with adaption to road traffic regulations such as turn restrictions andlocal access. The skilled person will appreciate thatstrong-connectivity indicates that travel is possible in both directionsbetween two nodes (i.e. from A→B as well as B→A).

Thus, referring to both FIGS. 2 and 4 it can be seen that dead-ends suchas the cul-de-sac 250, redundant loops 252, etc. have been deleted.However, it will be seen that a node (eg 400 in FIG. 4) remains at theorigin of the road-segments that have been removed. This is for reasonsdiscussed hereinafter.

Thus, in reducing the network of FIG. 2 to that shown in FIG. 4navigable segments have been removed for which search acceleration datacan subsequently be recovered; i.e. removing navigable segments havebeen removed from the network which form parts of the network that aresufficiently small according to some predetermined criterion and thatmay be disconnected from the rest of the network by removing a set ofnavigable segments that fulfils some further predetermined criterion.For example, the search acceleration data for node 302 may be readilyused for the node at the distal end region of navigable segment 304 awith little affect on the performance of any route planning.

Subsequent to the reduction down to the core network (eg as shown inFIG. 4), the core network is partitioned to provide the regionsdescribed above. In the embodiment being described, the network ispartitioned according to multiway arc separators. The skilled personwill appreciate that in such a network if the road segments (i.e. thearcs) which are bisected by region boundaries are removed then the roadsegments that remain in any one region would not be connected to anyother region.

Partitioning Network—Step 1906

However, before partitioning is performed the following steps are made:

-   -   1. Islands are determined and partitioned independently. Islands        tend to be physically separated from other parts of the network        and link thereby by means such as ferry links, etc. These behave        differently from typical road segments (i.e. average speeds are        significantly lower, etc) and if such links are included in the        partitioning then the method does not perform as well as may be        expected.    -   2. Crossings, roundabouts and other junctions, which are        represented by more than one node in the network are contracted        so that nodes belonging to the same crossing, etc. do not end up        in different regions.    -   3. Simple paths (i.e. connections between two nodes without turn        possibilities) where all navigable segments share the same set        of characteristics (eg ferry segments, segments belonging to        pedestrian zones or gated communities, etc) are contracted to        reduce the input size of the network passed to the partitioning        system. For example, looking at FIG. 3, node 301 may be        collapsed onto the node directly below it; i.e. nodes are        collapsed onto one another if they have two or less than two        navigable segments connected thereto.

In further embodiments, complex junctions between navigable segments maycomprise a plurality of nodes. Such complex junctions may be collapsedonto a single node (i.e. nodes are collapsed, which occur at junctionsbetween navigable segments, onto one another in predeterminedsituations).

Embodiments of the invention being described employ a divide and conquerapproach which is outlined at http://labri.fr/perso/pelegrin/scotch. Themethods outlined herein divides the map to comprise a number of regionswhich are not based upon an area of the map but which are based upon thenumber of nodes contained within a region. Having nodes which are soorganised has the advantage that it can help to make routing using theregions more efficient because it helps to deliver regions havingsimilar local search diameters.

Each node has identity numbers associated therewith including a regionID and as such, nodes in the same region have same region ID numbers.Nodes belong to regions at L hierarchical levels. Level 0 is byconvention the coarsest level (used for long distance routing). LevelL−1 is the finest level.

Rather than setting an absolute number of nodes to be contained withinany one region it some embodiments of the invention may set a cap on themaximum number of nodes and allow some flexibility below this. Forexample, the method may specify a maximum number of 100 nodes per regionwhich could result in a spread of nodes per region of typically 60 to100 nodes. A cap is felt advantageous over a set number of nodes since aset number can result in regions of forced shapes which in turn lead tosub-optimal routing when using the regions.

Multiple Levels

In the embodiment being described, the partitioning is performed toprovide a plurality of levels of nested regions which is conceptuallyexemplified in FIG. 6. It will be clear from FIG. 6 that a hierarchicalnature exists with the coarsest level (0) being subdivided to providelevel 1, which is in turn subdivided to provide level 2 which is thefinest level.

The number of nodes in each region varies between levels and the coarserlevels (which tend to cover a larger geographical area) have more nodestherein than lower levels. As such, the coarser level in the embodimentbeing described (eg level 0) is typically used for long range routingpurposes whereas the finer levels (eg level 2) are used for routing atshort range.

A portion of the bit vector for each road segments comprises bits foreach of the levels. The number of bits is the number of regions in eachlevel.

To give an idea of the amount of data to encode (in a typical embodimentthe number of levels would typically be L=3):

-   -   global level=0 would typically have 100 regions.    -   intermediate level=1 would typically have 10 regions for each        region of level 0 (i.e. 100×10).    -   most detailed level=2 would typically have 5 regions for each        region of level 1 (i.e. 100×10×5).

Use of hierarchical levels is advantageous since it reduces, perhapssignificantly, the amount of processing that is required. In the currentembodiment being described 100×10×5 regions (i.e. 5000 regions). Thus,in a flat structure, having the same number of regions, would requiremethods outlined herein to refer to 5000 regions. However, embodimentsdescribed herein this can be reduced by referring to nodes in theappropriate level.

The number of levels and number of regions per level will typically betuned once various factors are known for a map. For example, how muchstorage can be allocated to the map and speed at which routing should beperformed. The skilled person will appreciate that there is a compromisein that as the amount of pre-processing is increased then the larger themap size becomes to hold the data, but the faster routes can becalculated using that map.

In one embodiment, there are 3 levels of regions. However, in otherembodiments there may be any number of levels. For example, there may beroughly any of the following number of levels: 1, 2, 4, 5, 6, 7, 8, 9 or10.

Thus, using the example above, a map of Europe and Russia whichtypically has 50,000,000 nodes and 120,000,000 road segments, the mostnaive encoding would use fixed size encoding for region ID for everynode at each level, and fixed size bit vector for each road segment ateach levels. Thus, the size of such a basic encoding can easily becalculated as follows:

-   -   each node region ID at level 0 would use log_2(100) bits=7 bits    -   each node region ID at level 1 would use log_2(10) bits=4 bits    -   each node region ID at level 2 would use log_2(5) bits=3 bits    -   each bit vector at level 0 would use 100 bits (100 regions minus        1 for the current region)    -   each bit vector at level 1 would use 10 bits (10 region minus 1        for the current region)    -   each bit vector at level 2 would use 5 bits (5 region minus 1        for the current region)

FIG. 6 shows a coarsest level of region 600, which in the Figureprovides 6 regions 1-6. Each of these regions is subdivided into furtherregions, in this embodiment nine sub-regions, as represented by thedashed line within the coarse level of region 600. Thus, the 6 coarselevel regions may be thought of as coarser level regions and the 9sub-regions may be thought of as finer level regions which are in aneighbouring region to the coarser level. In the embodiment beingdescribed a further level of subdivision is used in which each of theregions provided by the dashed lines are also subdivided, thus providingthree levels of partitioning but these are not shown in FIG. 6 for easeof reference (but are shown in FIG. 6a ). Other embodiments may ofcourse use more levels (eg 4, 5, 6, 7, or more levels) or fewer levels(eg 1 or 2 levels).

Thus, embodiments of the invention introduce so-called visibility areasfor finer-level regions step 1908. A visibility area of a k-region is aset of (k−1) regions, where the region is distinguishable on its own bitin the flag sets. Naturally, the visibility area always includes the(k−1) region to which the given k region belongs. Additionally, it maycontain some neighboured (k−1) regions. The visibility areas are to becomputed during the pre-processing and stored in association with thebit vector. Here the k regions may be thought of as the finer regionsand the (k−1) regions may be thought of as the coarser regions.

The relation between k regions and their (k−1) level visibility areascan be also seen from the opposite side: each (k−1) region knows itsoutskirts consisting of k level regions lying in the neighbourhood. Seenthis way, it can be seen that the flag sets of the road segments are nomore of fixed length throughout the whole map; instead, the bit vectorsin each 1-region have their specific length A+B+C+Noutskirts0+Noutskirts 1. Where A refers to the coarsest level of regions, Brefers to the middle granularity regions and C refers to the finestgranularity of regions (in an embodiment in which there are threelevels).

Sub-sequent pre-processing computes the visibility areas prior to theshortest path calculations to generate the bit vectors. The method offinding the visibility area can be described as follows:

-   -   Then, for each region R at each level but the topmost, the        neighbourhood graph is explored for each k-region, using a        breadth-first search in the region adjacency graph until the        following metrics exceed the selected thresholds:        -   graph-theoretical distance from R to the current region's            node        -   Euclidian distance between the median points of R and the            current region; or        -   any of the other distances described elsewhere herein.    -   then for each visited k-region, which lies close enough to the        start region, add its containing (k−1)-region to the visibility        area.    -   The “closeness” relation should take both the geographical        metric (e.g. distance between the region median points) and        graph-theoretical distance into account. (Thus, a region may be        “close” if it geographically far but linked to the current        region by fast connections. Likewise a region may be thought of        as “distant” even if it is geographically close if it is        difficult to travel between regions.)    -   The exact threshold values may be subject to experimental        tuning, as they depend on the map specific characteristics like        the average diameter of metropolitan areas, which are most        susceptible for negative effects described above such as        increased preprocessing, etc. Navigable segments with        extraordinarily long traveling time (like ferries or road        segments belonging to pedestrian zones) are hidden during the        adjacency graph traversal, this way visibility areas are always        confined to single islands or small archipelagos belonging to        the same region.

Thus, the regions visited during the breadth first search constitute theneighborhood of R. The inclusion-minimal set of the regions of the nextcoarser level completely covering the neighborhood is called visibilityarea of R. The reverse relation is called vicinity: the vicinity list ofa region Q (at level L) consists of all regions at level L+1 having Q intheir visibility areas.

To give a specific example, and referring to FIG. 6, examples of thevisibility areas are as follows:

-   -   If we decide that the minimal distance between each 1-region and        the border of its visibility area should be at least 1, then the        visibility areas for some selected 1-regions will consist of the        following 0-regions (the own 0-region can be omitted, as it is        always there):        -   15:        -   (i.e. level 1 region no. 15 has no visibility areas shown            since the own 0-level region can be omitted as it is always            present).        -   28: 5        -   (i.e. the visibility area of level 1 region no. 28 contains            the level 0 region no. 5).        -   37: 2, 5, 6        -   (i.e. level 1 region no. 37 has three regions in its            visibility area, namely level 0 regions no. 2, 5 and 6)

In addition to considering the level 0 neighbours of a level 1 region,the level 1 neighbours are also determined for each level 0 region. Thusas an example,

-   -   1: 21, 24, 27, 28, 41, 42, 43, 51    -   (i.e. for the level 0 region no. 1 the level 1 regions are: 21,        24, 27, 41, 42, 43, 51).    -   Thus, in this example, it can be seen that region 28 is listed        despite it not being in the leftmost column of region 2. This        for example might be because region 28 has fast links to region        1 and as such is close when considered in terms of time rather        than distance. The skilled person will appreciate that closeness        may be judged against other metrics such as greenness (least CO₂        or the like), etc.

Some embodiments may use the visibility area to reduce the amount ofpre-processing required to generate the search acceleration data byconstraining the calculation of the search acceleration data. Forexample, embodiments may use a reverse search from a destination region(e.g. region 24 of FIG. 6) to an origin navigable segment (e.g. inregion 27 of FIG. 6). This reverse search may be constrained in such away that it stops when all navigable segments in the visibility area ofthe destination region are reached by a shortest route. For example,assuming the visibility area of region 24 to be region 2, the reversesearch will stop once all navigable segments in region 2 are reached bya shortest route. The skilled person will appreciate that shortestroutes within region 2 might pass through regions not included in thevisibility area of region 24. For example, the shortest route betweentwo locations in region 2 might pass through region 1.

More specifically, this might be true for the shortest route between anorigin navigable segment in region 27 and a destination in region 24.This route has to be considered in order to generate the correct searchacceleration data for region 24. The skilled person will appreciate thatthe constrained search described above will generate correct searchacceleration data for routes passing through region 1: inside region 2,in particular in region 27, a search that uses the search accelerationdata will use search acceleration data for region 24; when it progressesto region 1, it will use search acceleration for the coarse region 2.Since region 1 is not in the visibility area of region 24, navigablesegments in region 1 will have search acceleration data for the coarseregion 2, but not for the finer region 24.

Additional, or alternative embodiments, may also use the visibility areato increase the search acceleration data stored for a given navigablesegment. Whilst this may increase the amount of pre-processing requiredit can increase the speed at which route planning can be performed usingthe map data containing such search acceleration data. Assuming thevisibility area of region 51 to include both region 5 and region 4, anaccelerated search to destinations in region 51 will already useacceleration data specific to region 51 present in region 4; i.e. theroad segments within region 4 have additional search information addedthereto indicating that they contain further minimum cost data to region51. This additional information may be referred to as a relevant bit.This is regarded advantageous to prior art which would only applyacceleration data to level 5 in region 4, thereby suffering from a muchbroader search front close to region 51.

Encoding of Neighbour Lists

FIG. 6a shows more detail of the levels that may be employed whencompared to FIG. 6. Level 0 is the coarsest level and may be thought ofas level k−1. For ease, in FIG. 6a only regions 1 to 4 are shown (i.e.602; 604; 606; 608). Each of these k−1 regions is further divided into 9regions (1-9) which may be referred to a k level regions or level 1regions. Further, each of these level 1 regions is divided into 4 k+1level regions (i.e. level 2 regions).

Generation of Bit Vector

Once the network has been partitioned into the hierarchical levels ofregions (3 in the embodiment being described) it is processed todetermine the least cost route to each of the regions and a bit vectoris created for each road segment within a region step 1910. Thus, asdiscussed above each road segment within any one region is analysed withrespect to a cost function to determine whether it is part of a lowestcost route to each of the other regions. A bit vector is generated forevery road segment in a region as is shown in FIG. 7 which, for ease ofcomprehension, shows a simplified bit vector.

It should also be appreciated that the lowest cost route is determined,not just a single time period, but is calculated for a plurality of timeperiods as described hereinafter.

This calculation is performed for the network shown in FIG. 4 (i.e. thereduced network). Portions of the network in FIG. 3 which have beenremoved are effectively collapsed onto the node from which theyoriginated. For example, the end-node of road segment 304 a shown onFIG. 3 is collapsed onto the node 302 in FIG. 3.

It will be seen that each bit vector comprises three columns: a leftmostcolumn 700 containing an identity number for the node at the start ofthe road-segment under consideration; a second column 702 containing theidentity number for the node at the end of the road-segment underconsideration and a third column 704 containing the bit vector for thatroad segment. Thus, it will be seen that each road segment is identifiedby two nodes, one at each end thereof.

Any suitable routing method may be used to determine whether a roadsegment is part of the lowest cost route. In this particular embodimentthe well known Dijkstra method is used to explore the whole network.

However, the amount of processing time may be reduced by employingvarious strategies. The skilled person that the techniques for reducingthe network described above will also reduce the amount of processingtime. Embodiments of the invention may employ any one or more of thefollowing:

-   -   calculate all bit vector entries corresponding to a region at        once. The shortest path tree is calculated in the reverse graph        for each navigable segment lying on the boundary. Such an        approach is advantageous as each region may be processed in        parallel thereby decreasing the processing time.    -   reduce recalculations of similar shortest path subtrees.    -   do not recalculate hit vectors which have already been        generated.

Thus, in summary one embodiment may perform the following in order togenerate the bit vectors:

Preparation Steps:

-   -   1. As the skilled person will appreciate the search through the        electronic map can be represented by a directed acyclic graph        (DAG). This graph and the adjoined data structures (turn costs        and long extension tables) are reversed.    -   2. The simple road segments with respect to the finest level are        contracted (i.e. the end nodes are collapsed onto one another as        discussed elsewhere). A road segment (i.e. path) is called        simple if it consists of one or more nodes of degree=2, all        lying in the same region of the given level, and the navigable        segments have identical attributes: for example “is a ferry”,        “is NoThrough”, and “IsNoDriving”.    -   3. For each region, the road segments of the road network are        sorted into three groups: outbound, inbound, and inner road        segments, depending on whether the head (i.e. from_node) and/or        tail (i.e. to_node) node belongs to the region. That is, if both        the head and tail are within the same region the road segment is        termed an inner road segment; if the head is within the region        but the tail is not then the road segment is termed an outbound        road segment; and if the tail is in the region but the head is        not then the road segment is termed an inbound road segment.    -   4. Special turn restrictions are put on all road segments        leaving the NoThrough and NoDriving areas.

The pre-processing routine proceeds in bottom-up manner, starting withthe finest partitioning level—i.e. level 2 in the embodiment beingdescribed. At each level of regions, the following steps are repeatedfor each region R:

-   -   1. Determine the exploration area of R. At the topmost level (eg        region 0 in the embodiment being described) it is the entire        graph, on finer levels it is the subgraph confined by the        visibility area of R (as described above).        -   Thus, at the intermediate level (i.e. level 1) the following            steps are only performed for the visibility area of the            level 0 region in which those level 1 regions are contained.            At level 0, which should be remembered is used for long            range routing, the road segments of the entire graph are            considered.        -   Collect the inbound road segments of the visibility area,            that is, road segments leading from nodes outside the area            into the area. Then collect the frontier road segments, that            is, road segments following the inbound road segments. The            road segment L 2 is called following L 1 (and L 1 preceding            L 2) if head(L 1)=tail(L 2) and the turn from L 1 into L 2            is not forbidden. The complex crossings are contracted to            single nodes for the purpose of finding the frontier road            segments. Ferry lines and road segments with “NoDriving”            attribute are not considered as frontier road segments.        -   Collecting the inbound road segments in this manner can            reduce, perhaps significantly, the amount of processing            required in the exploration steps described hereinafter. The            exploration step(s) can reduce exploration of the graph to            consider those routes to a given region which include an            inbound route.    -   2. For each outbound road segment of R, find the root road        segments and the number of exploration steps. If the outbound        road segment is a sole successor of at least one of its        predecessors lying within R, this outbound road segment is the        only root road segment, and a single exploration step is        performed. Otherwise, if the outbound road segment is        bidirectional (that is, drivable in both directions), then the        road segment itself and its opposite (inbound) road segment are        taken as root road segments of a single exploration step.        Otherwise, if the outbound road segment is unidirectional, then        each preceding inner road segment (and, if present, its opposite        road segment) is taken as a root road segment for a separate        exploration step. Finally, regardless of the kind of the        outbound road segment, for each traffic extension path running        through the outbound road segment, the starting road segment of        the extension (if it lies within R) is taken as a root road        segment for a separate exploration step.        -   On finer levels (i.e. all levels except level 0), the            outbound ferry lines are treated specially. As noted above,            ferry lines are ignored when determining the region's            neighborhood. If the head region of a ferry line does not            belong to the visibility area of R, then a single            exploration step will be performed with the ferry line being            the sole root road segment and the exploration area being            constrained to the head region itself.    -   3. Perform the scheduled exploration steps (described below).    -   4. Trace back the shortest paths from the road segments within        the exploration area to the root road segments. At all levels        except the topmost (i.e. Level 0), the ordering of the road        segments at which the respective trace starts is affects the        results. Suppose R is a level-L region (where L>0), then the        outbound road segments of level-(L−1) regions are processed        first, then the remaining outbound road segments at level L, and        so on towards the finest level; road segments which are inner        with respect to the finest level (and have not yet been removed)        are processed last. Whenever a road segment is encountered that        has already been visited in an earlier trace, there is no need        to follow that path a second time. While tracing, the        appropriate target bit vectors are set for each visited road        segment. At all but the topmost level (i.e. level 0), additional        actions take place:        -   after the path has first crossed some level-L region            boundary, that boundary line and all further road segments            on the way to the root road segment are marked with a            transit line flag;        -   the nodes where the shortest path makes a U-turn are marked            with a U-turn flag.    -   Finally, at all but the finest level, the correlation matrix        entries are filled.

After all regions of the level are processed, the graph is simplifiedfor the next level. First, all road segments not marked as transit linesare removed. Then the accruing new simple paths are contracted; nodesmarked as U-turn nodes are preserved.

Finally, the bit vectors are propagated to the road segments removedbefore processing this level, according to the correlation matrix.

Correlation Matrix

Some embodiments of the invention use a correlation matrix which storesrelationships between target regions needed to set the bit vectors onthe road segments. At each level L except the finest level, a newcorrelation matrix is created and used. At level L, the rows of thematrix are indexed by level-(L+1) regions, the columns are indexed bylevel-L regions, and each matrix entry is a set of zero or morelevel-(L+1) regions. At the lower levels, most matrix entries are equalto the empty set, i.e. the matrices are sparse.

The purpose of a correlation matrix is to help setting bit vectors onroad segments which have been deleted at earlier stages. These roadsegments are not contained in the directed acyclic graphs resulting fromthe level-L exploration steps, but they would be if they had not beendeleted. More precisely, the correlation matrix is used to set bitvectors to some level-L region S (where L is not the finest level) onroad segments in the exploration area of S which have been deletedduring the computations at some level>L. For a level-(L+1) region Rcontained in the exploration area of S, the matrix element M[R, S] willfinally be a set of level-(L+1) regions at the boundary of thevisibility area of R, such that all shortest paths (in the reversedgraph) from S to R pass through one of those regions.

When the matrix is created, all entries are initialized to the emptyset. Then, for all level-L regions S, the following two actions areperformed.

-   -   1. Matrix build-up: For each exploration step with a root road        segment l in or on S and the resulting directed acyclic graph D,        for each level-(L+1) region R contained in the exploration area        of S, and for each inbound road segment l′ of R, the matrix        element M[R, S] is updated as follows:    -   Denote by A the exploration area of R (as computed earlier for        level L+1). Trace the path in D from l′ back to 1 and check        whether it leaves A: if a road segment on this path goes from a        level-(L+1) region T to a level-(L+1) region T′, where T is        still contained in A, but T′ is not, then T is added to the set        M[R, S], and the next l′ is processed.    -   2. Reading the matrix: for each road segment in the exploration        area of S which had been deleted before the level-L computations        started, let R be the level-(L+1) region where that road segment        ends (again, with respect to the reversed graph). Now the bit        vector bit for region S on that line is set to the logical OR of        the bit vector bits for region T, where T ranges over all        elements of M[R, S].

Note that the bit vector bit for each T will have been set at an earlierlevel either directly from some directed acyclic graph or in theanalogous procedure involving a correlation matrix at some lower level.

Exploration

The exploration step consists of building a directed acyclic graph ofshortest paths rooted at the given road segment (pair). This isaccomplished by using a variation of the well-known Dijkstra method forshortest path (i.e. minimum cost) computation. The term “shortest” ischosen due to the tradition; actually, the objective function to beminimized can be freely chosen, for example, as the travel time orestimated fuel consumption, or any of the other factors discussedelsewhere.

One embodiment uses a weighted sum of travel time, path length, andother penalty terms suppressing undesired turns and maneuvers.

The following modifications are made to the classical (Dijkstra) method:

-   -   1. It works on the road segment graph, i.e. the items being        visited, relaxed, etc. are road segments, not nodes. This is        useful to allow the method to account for turn restrictions        and/or traffic extensions.    -   2. The objective function in the label is a vector of pairs        (travelling time, cost) for a fixed set of arrival time slots at        the root road segment. The time slots are chosen such that all        relevant traffic modes are covered (free flow, weekday morning        rush hour, evening rush hour, etc.). This is expanded on further        below in the discussion about assessing the cost function at a        plurality of time periods.

3. More than one label can be stored for a given road segment. If thesets of pending (unfinished) traffic extensions on two labels are notequal, then the labels itself are called independent and both keeppropagating over succeeding road segments. Otherwise, if the relationbetween cost function values for different arrival time slots is notalternating, i.e. one label is unambiguously better than another, theworse label is discarded. Otherwise, a new label is created by mergingthe better values for each time slot, which is propagated in lieu of theoriginal one. The predecessor set of the merged label is then the unionof the predecessor sets of original labels.

4. Special U-turn labels are created on each bidirectional road segment.They encode the possibility of starting the real (non-reversed) route inboth directions. U-turn labels are not propagated and may not be mergedwith normal labels. However, they influence the backtracking phase whenthe bit vectors are set: a shortest path is flagged only if the startinglabel is not worse than the U-turn label on the same road segment.

5. At the finer levels, where the exploration area is restricted to aset of regions, the frontier road segments, as defined above, arepermanently watched. As soon as all frontier road segments are reachedby the search front, the watch comb is built up from the largest(=worst) cost function values per time slot. Then a label on a roadsegment outside the exploration area, when popped off the heap, ispropagated only if its cost function value lies below the current watchcomb in at least one time slot. If an exploration area stretches overseveral islands, a separate watch comb is maintained for each island.

Time Varying Functions

Some embodiments of the current invention may calculate the bit vectorshowing the minimum cost route across the network at a plurality of timeperiods rather than at a single time. The skilled person will appreciatethat the lowest cost route through a road network may vary with time dueto the influence of traffic density, etc. Therefore, for any one nodethere may be two or more minimum cost paths, each one for a differenttime. In this embodiment, the bit vector is not coded with a timereference for when the minimum cost paths are applicable. The bit vectoris simply set to identify a navigable segment as either being part of aminimum cost path or not. Therefore, when routing using the minimum costdata, the routing algorithm will have to consider all possible minimumcost paths from a node. This process is now briefly described with theaid of FIG. 7 a.

In a standard Dijkstra exploration of a network, as the network isexplored, the method uses the total cost incurred to date to get to thatpoint in the network plus the expected cost yet to be incurred.

Thus. some embodiments utilise a function as opposed to a discrete valueto make the cost evaluation at each node. Thus, in FIG. 7a each node (eg750) of the graph 751 that is being explored has a cost functionassociated therewith which identifies how the parameter being explored(eg time, fuel expended or the like) varies with time. The node 750 maybe thought of as an origin node. In some embodiments, an origin node maybe synonymous with an origin navigable segment.

The cost function may be associated with a road segment as opposed tonode.

The method then processes the expended cost to add the estimated costsby summing the function at the current node with the cost that has beenaccumulated to date to generate new function. The example shown in FIG.7a at 752 shows a cost function that has been generated at node 750 bythe search method and shows how the travel time (y axis) varies with thedeparture time (x axis). It will be seen that the travel time increasesat points 754 and 756 due to the morning and evening rush hours.

In one particular embodiment, the cost function (for example the averagespeed on a road segment) is stored at 5 min. intervals; i.e. it is aquantised rather than continuously varying function with a time periodof 5 min.

The bit vector for a road segment is set if that road segment is part ofthe lowest cost route at any time period.

Projecting Core Data to Full Network

Above it was described how the network contained in the map was reducedin order to reduce the number of road segments and nodes that must beconsidered by the partitioning method. However, the nodes that weredeleted in the reduction step should also be considered further in orderthat routing methods can still generate routes to or from the deletedroad segments and nodes.

As such, the deleted nodes and road segments are assigned to the sameregions as the node to which they are connected in the core network.

Compression

As discussed, the generated bit vectors are significant in size andtherefore it is desirable to compress the information. Embodiments ofthe invention may perform this in different manners. However, oneembodiment utilises various techniques to compress, coalesce and/orcorrelation of the bit vectors followed by a subsequent Huffman encodingof the bit vectors.

Thus, some embodiments may try and ensure that there is an unevendistribution of bit vectors since this can help to ensure that theHuffman encoding is more efficient than would otherwise by the case.

For example if the bit vectors are distributed as follows:

-   -   00000 . . . (19% of the time)    -   11111 . . . (49% of the time)    -   ????? . . . (2% of the time)        then it may be desirable to manipulate the bit vectors prior to        Huffman encoding to having a more uneven distribution such as:    -   00000 . . . (79% of the time)    -   11111 . . . (19% of the time)    -   ????? . . . (2% of the time)        Reduction in Generated Bit Vectors

In order to reduce the amount of Bit Vectors that need to be generatedembodiments of the invention may use any one or more of the followingstrategies:

-   -   region IDs are not used for all nodes and are only generated for        navigable nodes (eg nodes corresponding to railways are        ignored).    -   bit vectors are not needed for all road segments and may be used        for decision road segments around decision nodes. Decision nodes        & decision road segments can be determined by looking at road        segment data (as described in this document).    -   even though there are many possible bit vectors, some are far        more frequent than others, so special encoding can be used for        the most frequent ones (eg 000 . . . 000 and 111 . . . 111).    -   bit vectors that are not 000 . . . 000 or 111 . . . 111 still        often have either most of their bit set to 1, or most of their        bit set to 0. So Huffman code of partial blocks should encode        them fairly efficiently.    -   bit vectors are often identical in nodes close to each other, so        delta encoding can encode them efficiently.    -   different regions can be made to have more similar bit vector        patterns by reordering destination region IDs per source region        (idea is described in this document)    -   Or of all bit vectors around road segments of a node should        always give 111 . . . 111. That properly can be used to encode        bit vectors more efficiently.

Some of these are discussed in further detail below.

It is worth noting at this point that techniques described here aim toreduce the size of the bit vectors. However, it is noted that randomaccess to the data is required by devices which use the map data forrouting purposes. Generally, efficient encoding of data requires avariable size which would however prevent random access to the data.

As such, embodiments of the invention may use a trade-off in which datais encoded as a series of pages, which are indexed, and then utilisesvariable encoding within those pages. In such embodiments, random accessis achievable to each page (through the indexing). Once a page has beenaccessed embodiments, may subsequently decode the entire page. Thisprovides a trade-off between efficiency and map size—increasing thenumber of nodes per page reduces the map size but slows data access. Oneparticular embodiment of the invention uses 16 nodes per page. It willbe appreciated that any one node may well have a different number orroad-segments leaving that node.

As such, even though there may be the same number of nodes there may bea variable amount of road segments per page. Further, differentcompression may well occur for each of the bit vectors stored on eachpage.

Such a structure may lead to a map format as shown in FIG. 8. In thisThe number ‘n’ is stored within the header and may be altered fordifferent maps in order to optimise the performance for that map.

Tuning ‘n’ is a trade-off between map size and access speed whendecoding map data:

-   -   a large value of n will group many nodes together which is good        for map compression, but bad for speed of random access to the        data.    -   a small value of n will group few nodes together which is good        for speed of random access of the data but bad for map        compression.    -   ‘n’ may be set to 4 for example i.e. pages of 16 from-nodes (a        from node being at start end of a road segment—i.e. column 700        of FIG. 7) but keep in mind that each from-node has several        to-road segments so assuming 3 to-road segments on average, each        means that each page store the equivalent of ˜48 road segments.

In this format, there is a different format for data depending upon thelevel of region that is encoded. FIG. 9 shows an example of a format forlevel 0 (i.e. the coarsest regions) and FIG. 9 shows an example formatfor other levels of region.

The bit vectors and related information are stored in a data structure,the format of which is shown in FIG. 8 which comprises the following: aheader 800; Huffman trees 802 used in Huffman encoding described later;region count in each hierarchy 804 (empty if constant number of regionsper level); Region neighbours 806 (empty if no region neighbours);region ID remapping tables 808; bit vector page index (2^(n) nodes) 810;and the region ID and bit vectors 812. The data structure holding thebit vectors may be held within a single file or may be held within aplurality of files.

In some embodiments the map header 800 is arranged to contain furtherinformation indicating the following:

-   -   maximum number of levels    -   length of the shortest neighbour list.    -   length of the longest neighbour list.    -   byte offset of the section which contains all the neighbour        lists.

The or each file holding the information may have a section to encodethe neighbour lists. The size of all lists are encoded first. Eachlength of list is encoded relatively to the shortest list length, on afixed number of bits determined byBitsRequired(longestListLength−shortestListLength). Notice that if alllist have the same length, then no bit is needed to encode the lengths.

Then follow the content of all lists. Each list is made of severaltuples of neighbour region IDs:

pairs at level 0, 3-element tuples at level 2, etc.

Notice that the from-region tuples (portion before ‘:’ in ASCII file)are not encoded. They are implicit since lists are stored for allregions in ascending order. For example, if a map has 3 levels with100×10×5 (100 regions at level 0, 10 regions at level 1, 5 regions atlevel 2), then:

-   -   at level0, the lists are stored for from-regions 1, 2, 3, . . .        100 (100 lists in that order). Each of these lists contains        pairs.    -   at level 1, the lists are stored for from-regions 1.1, 1.2, 1.3,        . . . 1.10, 2.1, 2.2, . . . 2.10, 3.1, . . . 100.9, 100.10 (1000        lists in this order). Each of these lists contains 3-element        tuples.    -   at level2: nothing is stored since its the last level so there        are no neighbors.

Each component in a tuple is stored as n bit. The number of bits foreach level is determined from the number of regions at the correspondinglevel. So it is possible to access a list at random. In the case of 3levels 100×10×5, encoding a tuple a.b.c would use 7 bits for a (becausethere are 100 regions at level 0), 4 bits for b (because there are 10regions at level 1), and 3 bits for c (because there are 5 region atlevel 2).

Example: let's assume a partitioning of 100×10×5 regions: 100 regions atcoarse level 0, 10 at intermediate level 1 and 5 at detailed level 2.

In file at level 0, the section containing the neighbour lists willcontain:

-   -   100 numbers indicating the length of the lists for the 100        regions at level 0. Number of bits is computed from        BitsRequired(longestListLength−shortestListLength). Each number        is relative to the shortest list at the level (shortest list        being stored in header).    -   Then follow the content of the 100 lists (100 pairs). The first        element of each pair is encoded on 7 bits (because there are 100        regions at level 0) and the second element of each pair is        encoded on 4 bits (because they are 10 regions at level 1).

In file at level 1, the section containing the neighbour lists willcontain:

-   -   100*10=1000 numbers indicating the length of the lists for the        1000 regions at level1.    -   the follow the content of the 1000 lists (10003-element tuples).        The first element of each tuple is encoded on 7 bits (because        they are 100 regions at level 0), the second element of each        tuple is encoded on 4 bits (because they are 10 regions at level        1 in each level-0 region) and the third element of each tuple is        encoded on 3 bits (because there are 5 regions at level 2 in        each level-1 region).

In file at level 2, nothing needs to be stored since it is the lastlevel.

Header 800

Typically, the header used in embodiments of the invention is small, andas such the size does not need to be optimized in order to reduce itssize. Typically everything is byte or word aligned for convenience:

-   -   (4 bytes) encoding version (increased every time map format        changes)    -   (4 bytes) map flags (to turn on or off features, 0 initially but        can be used later if we need to add optional features)    -   (4 bytes) total number of nodes in map    -   (4 bytes) total number of road segments in map    -   (4 bytes) byte offset of section Huffman trees    -   (4 bytes) byte offset of section region blob    -   (4 bytes) byte offset of section region page infos    -   (4 bytes) byte offset of section bit vector page infos    -   (4 bytes) byte offset of section variable size records    -   (4 bytes) maximum bit vector page in bits (can be used by route        planning methods to pre-allocate worse case for bitstream        decoder at startup)    -   (4 bytes) average hit vector page size in hits (used to        interpolate hit vector page position)    -   (4 bytes) minimum bit vector page delta (used to make all        deltas>=0, avoiding to store bit sign)    -   (2 bytes) maximum size of bit vector history (can be used by        route planning methods to pre-allocate history buffer at        startup)    -   (2 bytes) maximum number of road segments per page (currently        not used)    -   (1 byte) Apollo level of this file.    -   (1 byte) bits per bits vector    -   (1 byte) bits per bit vector page delta (field in fixed size        record of bit vector pages)    -   (1 byte) bits per blob index (field in fixed size record of        region page info)    -   (1 byte) hits per region count (field in fixed size record of        region page info)    -   (1 byte) bits per non trivial bit vector block    -   (1 byte) log_2( ) of region node page size    -   (1 byte) log_2( ) of bit vector page size    -   (1 byte) number of Huffman trees to encode local region IDs    -   (1 byte) number of Huffman trees to encode bit vector history        codes        Huffman Trees 802    -   Huffman tree to encode number of road segments around each node:        tiny, only 10 codes or so, only present in file at level 0)    -   Huffman tree to store a block of non trivial bit vector: largest        Huffman tree, the larger the better for compression but the more        memory is required in route planning methods (trade-off between        map compression and memory usage in route planning methods).    -   Huffman tree of bit vector delta codes when history size is 0:        tiny, only 3 codes    -   Huffman tree of bit vector delta codes when history size is 1:        tiny, only 4 codes    -   Huffman tree of bit vector delta codes when history size is >=n:        tiny (number of Huffman trees stored in header)    -   Huffman tree for region ID when there are 3 regions in a region        page: tiny, only 3 codes    -   Huffman tree for region ID when there are 4 regions in a region        page: tiny, only 4 codes    -   Huffman tree for region ID where there are >=n regions in a        region page: tiny (number of Huffman trees stored in header).        Region Remap Table 804 and Region ID Lists 806

Although smaller than other parts of the file format of FIG. 8, theregion ID's 806 may also be compressed as is exemplified in FIG. 11. Inthis, geographical correlation may be used in order to reduce the amountof data used.

Each region page stores a list of the distinct regions in that regionpage. This list is expected to be small in most cases (in fact manypages are likely to contain only 1 region at least at level 0). Lists ofregion have variable size. The data within the pages should beaccessible on a random basis (i.e. Random Access) and as such a fixedtable size is used to allow this.

Each list of distinct regions is ordered by frequency of nodes in eachregion: the first element of the lists corresponds to the region withthe largest number of node in the page, the last element of the list isthe region with the least number of nodes in the page.

Each nodes in region pages, we can encode its region ID using a localregion ID (local to the page).

This local ID is the index of the region in the page (which is a smallinteger, often 0 since 0 corresponds to the most popular region in theregion page.

Region IDs of nodes are stored as follow:

-   -   A Region Array, containing region ID′, stores all possible        overlapping lists of regions in pages. Lists of region are        consecutive region IDs in that array. Lists can (and do)        overlap. The array does not store the start and end of each list        (this is done by the region page info table).    -   The region page info table is a fixed size record table (hence        accessible at random) and each record contains the index in        array of beginning of a list+number of items in the list.    -   Each node contains a local node ID (local to it's page).    -   Each of these concepts are further defined hereafter.        Region Array

The region array encodes all possible region lists of pages. It is asimple array of region IDs where list of region IDs can overlap. Itssize should be small since lists overlap. The region array is furtherdescribed in the section Region page infos.

Region Pages Infos

Specifying a list of region IDs in region page table uses 2 fields inthe fixed size record of region page info table:

-   -   a region count (number of regions in this page, expected to be        small).    -   an offset into an array of region lists (where list of region        begins).

In one embodiment, this is as described as in FIG. 9.

The offset field points into the region array: fixed size records with 1byte per region ID are enough, for example, assuming that there arealways less than 256 regions in each level, which is a fair assumption(but making it larger than 8 bits is easily possible if 256 region maxper level is deemed too restrictive). The region count in the regionpage table record indicates how many regions are to be considered in thearray at the specified offset.

If several regions have the same list, they can point to the samelocation, which should be compact since we can expect many pages toeither share to same lists, or to share portions of the same lists.

This is explained in more detail with reference to FIG. 9 which shows anembodiment having pages of 2^nr nodes (nr=9 for example to group 512nodes).

Notice how compact the array 900 of region IDs can be because severalpages can point to the same location or overlapping locations in thearray (labelled region blob in the figure). In fact, increasing thenumber of pages may not increase the size of the array because each pagethen overlaps less regions so the possibility of combinations isreduced. So this array should allow to create many pages withoutrequiring too much map space nor much memory on the device in which thegenerated map data is loaded.

The method aims to keep the array 900 containing list of region ID assmall as possible. The method aims to reuse the same list of region IDas often as possible in the array. The method is free to reorder thelast 2 elements of the list since they would not influence the size ofHuffman codes.

For example, when a list contains 2 region 10 and 34, it is equivalentto store the list 10, 34 or 34, 10 (regardless of the frequencies) sincethe Huffman tree uses only 1 bit in all cases when there are 2 nodesonly. In other words, the ordering by frequency is relaxed for the last2 regions. Similarly, a list of 3 elements 10, 34, 40 can also be storedas 10, 40, 34, since only the first code 10 (most frequent) will use 1bit and the other codes 40 and 34 and both use 2 bits (regardless or theorder).

Thus, looking at FIG. 9, it can be seen that the array 900 stores twovalues: a length and an offset from the beginning of the region data.Thus, taking the first row (3: 0), this refers to three pieces of dataoffset by 0 from the start of the file (i.e. 10, 34, 40). Taking as afurther example, the array entry (1:2) refers to a single region (i.e. alength of 1) with an offset of two from the beginning of the file; (i.e.region 40).

In an alternative embodiment, the region page information is encodedaccording to the following method:

This section encodes the number of sub-regions in each region. Thenumber of sub-regions may be variable per level. However, often thenumber or sub-regions is constant for each level. The number ofsub-regions is encoded relatively the min number of regions at eachlevel and using log_2(max_number_of_regions−min_number_of_region) bits.So if the number of regions is constant, then 0 bits are used to encodethe region count and this section is empty. The min and max number ofregions are stored in the header of the side-file.

Encoding of region neighbours section (neighbourhoods being discussed inrelation to FIGS. 6 and 6 a)

This section encodes for each region hierarchy at given level L a listof region neighbours at the more detailed level L+1. For example, aregion 3.9 at level L=1 may have the following list of neighbours atlevel L=2: 3.5.4 3.6.3 3.6.4 4.7.1 4.7.3. As discussed elsewhere thelist of neighbours may be used to increase the speed of thepre-processing used to generate the or each side-file. This section issplit into 2 sub-sections:

-   -   a subsection to encode length of all neighbour lists (as many as        there are regions at the given level). The length is encoded        relatively to the shortest list and then umber of bits is        computed as log_2 (length_longest_list−length_shortest_list). If        all lists have same length, then 0 bits is used to encode        lengths (and thus section is then empty).    -   a subsection to encode all the neighbor lists (as many as there        are regions at the given level).        Encoding of Region ID Remapping Tables

This section is encoded in the side-file of level 0 only. It encodes abi-dimensional table which is used to reorder and coalesce bits in eachregion at level 0 (in order to encode bit-vectors efficiently,coalescing and bit reordering are described further below in thisdocument). Reordering and coalescing of bits in bit vectors is done tooptimize Huffman encoding of bit vectors. This table is used by routeplanning methods to find the bit position in the bit vector to decodewhen knowing:

-   -   the from-region ID of the current node    -   the original to-bit index (i.e. bit index after decoalescing bit        vector bits)

The 2 indices of the bi-dimensional table are:

-   -   from-region ID    -   destination-bit index (region of destination)

This section is made of 2 sub-sections:

-   -   a section to encode the number of coalesced bits for each region        at level 0. The number of bits used to encode each number is        log_2(max_number_of_coalesced_bits)    -   a section to encode the bit remapping table. Since when routing,        the destination-bit does not change (destination remains the        same while routing) but the from-region ID changes (depending on        nodes explored while routing) the matrix stores by rows of        destination-bit. In each row, the bit-reordering number is        stored for each from-region. Route planning methods should        typically load only 1 row in memory corresponding to a given        routing destination while routing. The route planning method        does not need to store the entire bidimensional matrix in        memory. Route planning methods can access that row at random.        The number of bits used to encode each remapping entries is        computed as log_2(max number of coalesced bits).

FIG. 10 expands the bit vector section 812 of the file shown in FIG. 8for the level 0 region (see FIG. 6). It is seen that each page comprisesa road segment count, regions ID's and the bit vectors.

FIG. 11 expands the bit vector section 812 for the file shown in FIG. 8for levels other than level 0. It can be seen that for other regionsonly the bit vectors are stored and not the road segment count orregions ID's which are stored for level 0.

This is because at the finer levels because each node has its regionnumbers for all levels stored in the side-file at level 0. The reasonfor storing it that way is to reduce the number of files that have to beaccessed during any route planning using the side-file

Encoding of Bit Vectors 810, 812

The table 810 contains fixed size records. From-node IDs are grouped inpages of 2^(n) together.

It is convenient to group data in pages of multiple consecutive nodesbecause it is expected that bit vectors have similar patterns forseveral road segments in the same neighbourhood. By using pages, it ispossible to encode several road segments in delta and achieve goodcompression. Similarly, it is possible to encode region IDs of nodes indelta in pages. On the other hand, it means that accessing data of oneroad segment requires to unpack data of several road segments (no directrandom access). Having to unpack several nodes or road segments toaccess the data of one road segment or node may be deemed acceptablesince:

-   -   data can be cached so extra data read when accessing one road        segment is often not useless. It may be that this extra data        will be useful shortly afterwards (this is similar to read-ahead        parameter of disk caching).    -   Routing using the bit vectors reduces the size of the expansion        search by an order of magnitude when compared to Dijkstra A*        routing. By grouping data by pages, only a small portion of the        map still needs to be decoded (pages along the actual path).    -   it should significantly reduce the encoded data size thanks for        delta compression of region ID & bit vectors.    -   pages reduce the size of indexing since the data will be stored        in a side-file as described.

Each record within the table 810 contains a ‘delta’ field which is usedto find the position of the beginning of the variable size of each page(delta to an interpolated position). The number of bits for each deltais stored in the header.

In order to access the region ID and bit vectors 812 a decoder maycompute the estimated offset of the beginning page by doing a linearinterpolation:interpolated_offset=from_node_id*avg_page_size

Where avg_page_size is the average page size in bits stored in theheader (possibly in fixed point to improve precision). The offset of thedata can then be computed as follows:offset=interpolated_offset+min_delta+delta

Where min_delta is the minimum value of all delta fields for all pages(stored in header) and delta is the unsigned field stored in the page.The min_delta value ensure that all delta fields are positive value (nobit sign to store).

Variable size records are accessed through ‘delta’ field of thepreviously described bit vector page infos.

Each record contains the data of 2^(n) nodes (region IDs of from-nodesand bit vectors of their attached road segments at all levels). The sameindexing scheme will thus be used for all levels.

Variable size records store:

-   -   page code—a code indicating for the entire page as to whether or        not the nodes within that page are part of the same region;    -   the number or road segments around each node in the bit vector        page (only stored at level 0 since it would be the same for all        levels);    -   region IDs of the from-nodes in the page, one ID per level        (information for all levels stored in file at level 0)        bit vectors of road segments around nodes in page (only around        nodes which have >2 attached road segments) at level i only.        This is the biggest portion of data.    -   Encoding of number of road segments around each node

For each of the 2^(n) nodes in a bit vector page, a Huffman code encodesthe number of road segments around the node. This information is notspecific to all levels and it is only stored in the file at level 0(ap_0_*.dat).

Knowing the number of road segments around node is used to decode thebit vectors (see 1000, FIG. 10). This information is redundant withinformation already present in the in other files but it makes it easierand faster to decode bit vectors in pages without having to look up thatinformation elsewhere; thereby a small increase in size provides anincrease in performance.

Encoding of Region IDs in Variable Size Records

Region ID of nodes 1002 are encoded in the variable size records rightafter encoding of number of road segments 1000 around each nodes. Inorder to perform routing using the bit vectors generated in thepre-processing access is generally needed to region IDs 1002 at alllevels for a given node, region IDs of all levels are stored in the samefile near each other rather than splitting them in different files perlevel.

A bit vector page of 2^(n) nodes (n=4 for example) and with 3 Apollolevels would thus store node IDs as follows:

node#0: local_region_id_level_0 local_region_id_level_1local_region_id_level_2

node#1: local_region_id_level_0 local_region_id_level_1local_region_id_level_2

node#2: local_region_id_level_0 local_region_id_level_1local_region_id_level_2

. . .

node#15: local_region_id_level_0 local_region_id_level_1local_region_id_level_2

Additionally:

-   -   Nothing is encoded around nodes with 1 or 2 attached road        segments (i.e. for nodes for which we store 0 as number of        attached road segments).    -   When the bit in page code is set at a given level, then it is        knows that all nodes are in the same region ID at that level and        the region ID at that level is then encoded only once (for the        first node with >=3 attached road segments). The number of bits        to encode the region ID is log_2(regionCount−1).    -   Except for the first node in a page where a region ID is        encoded, a bit is also encoded before encoding each region ID.        This bit indicates whether the region ID is identical to        previously encoded node ID at the same level. When this bit is        set, there is no need to encode the region ID since it is the        same as previously encoded at that level. When this bit is 0, we        encode a region ID with log_2(regionCount−1) bits. Since many        consecutive nodes are in the same region, we often only need 1        bit to encode the region ID.        Huffman encoding of the local region index is efficient because:    -   regions are sorted by frequencies in each region page (so local        index 0 is more frequent than local index1, . . . )    -   there are distinct specialized Huffman trees for each number of        region in page (1 Huffman for 3 region in page, 1 Huffman tree        for 4 regions in page, etc). Huffman trees are small and as such        it is possible to store several without using significant        amounts of memory.    -   having 3 regions or more should be rather rare anyway, at least        at level 0 (but it won't be rare at other levels).        Encoding of Bit Vectors in Variable Size Records

Each variable size record contains bit vectors for all road segmentsaround nodes in the page. Bit vectors are encoded only around nodes with3 or more attached lines (road segments). For nodes with 1 or 2 attachedroad segments, routing methods can implicitly give bit vectors values111 . . . 111) to those nodes.

The to-nodes are not encoded.

With reference to FIG. 7, it is noted that a road segment may bespecified by two nodes; one at each end thereof. Thus, when direction isconsidered a node at the beginning of a direction may be referred to asa from_node and a node at the end may be referred to as a to_node.

Various properties about the bit-vectors are used within the encoding tomake it efficient:

-   -   Many of the bit vectors are 000 . . . 000 or 111 . . . 111.    -   For other values of bit-vectors (i.e. non 000 . . . 000 or 111 .        . . 111) there is likely to be repetition and the same value        will likely be repeated.

Bit vectors are encoded as a first Huffman code and optional furtherHuffman codes. The first Huffman code indicates whether the bit vectoris:

-   -   code 0 for trivial bit vector 000 . . . 000    -   code 1 for trivial bit vector 111 . . . 111    -   code 2 or to indicate a non-trivial bit vector not yet        encountered in the page. In that case, and only in this case,        other Huffman code follow to encode the newly encountered bit        vector.    -   a code>=2 when bit vector is identical to a previously        encountered bit vector in the current page (ignoring trivial bit        vectors 000 . . . 000 and 111 . . . 111). This encoding thus        uses the history of previously encountered code in the page. The        code then actually gives the index in history of all previously        encountered codes.

Other than this Huffman code, more information needs to be encoded onlyin the case of non-trivial bit vectors not found in history (code=2). Inthat case, right after Huffman code==2, is encoded:

-   -   a negated bit    -   Several Huffman codes to encode by blocks of N bits the bit        vectors for n regions (N and n are given in the map header). For        example. Encoding 100 regions (99 hits hit vectors) using blocks        of 11 bits requires encoding 9 Huffman codes (9×11=99).

Since most bit vectors contain either mostly 0s or either mostly 1, thenegated bit indicates whether the bit vector is stored negated or not.This enables storage of codes in Huffman tree containing by far mostly0s (thus improving Huffman encoding of the blocks). The negated bitexists only if the size of the blocks is smaller than the number ofregions, which is the case in practice at level 0 but at level 1 or 2,the whole bit vector might be encoded in 1 block only so negated bit isnot needed.

If there are 100 regions; N=100 (hence 99-bit vectors), the first blockencode bits for destination regions 1 to 11, the second block encodesregion 12 to 22, etc. In the first block, the LSB (0x1) corresponds todestination region 1, the next bit (0x2) corresponds to region 2, thenext bit (0x4) corresponds to region 3, etc.

For bit vectors using history, the depth of the history array is thenumber of previously encountered distinct bit vectors in the page(without taking into account trivial bit vectors 000 . . . 000 and 111 .. . 111). A different Huffman tree is used whether the history vectorcontains 0 elements, 1 element, 2 elements, 3 elements, etc. Multiplyingthe Huffman trees is acceptable since all the Huffman trees are smalland as such significant storage is not required:

-   -   when history has 0 elements, Huffman tree has 3 codes: 0 for 000        . . . 000, 1 for 111 . . . 111, 2 for new bit vector.    -   when history has 1 element, Huffman tree has 4 codes: 0 for 000        . . . 000, 1 for 111 . . . 111, 2 for new bit vector, 3 for same        as element #0 in history.    -   when history has 2 elements, Huffman tree has 5 codes: 0 for 000        . . . 000, 1 for 111 . . . 111, 2 for new bit vector, 3 for same        element #0 in history, 4 element #1 in history.    -   etc.

The size of the bit vector page is expected to be small (2^(n)from-nodes for example) so the number of Huffman tree is expected to besmall.

However, it is possible to limit the size of the Huffman tree to amaximum value: eg. whenever history contains more than H elements, asingle Huffman tree will be used (value H is stored in map header).

This encoding encodes only distinct bit vectors in each page+some codes.

The encoding is more efficient in size with large index pages but at thecost of slowing down decoding in order to use the bit vectors forrouting purposes (more bit vectors to decode in pages).

Statistics

Here are detailed statistics for a file format when encoding Benelux in254 regions (1 level). The following input parameters were used:

-   number of bits per bit vector block: 11-   number of nodes per bit vector page: 2^4=16-   number of nodes per region page: 2^9=512

Statistics are provided to give an idea of the map form in term of mapsize and illustrate the description of the map format on some real data:

--- Global statistic counters:  node count 1598632  line count 1598632(100.000%)   skip lines around nodes with 1 lines 220180 (13.773%)  skip lines around nodes with 2 lines 727138 (45.485%) --- Stats atlevel = [0]: Map counters 87437736 (100.000%)  encoded trivial arp-flags000 . . . 000 1310914 (31.651%)  encoded trivial arp-flags 111 . . . 111913348 (22.052%)  encoded arp-flags in history 362432 (8.751%)  encodedarp-flags not in history 607717 (14.673%)   negated blocks 235171(5.678%) Map size (in bits) 87437736 (100.000%)  global header 496(0.001%)  Huffman trees 28808 (0.033%)  region blob 52664 (0.060%) region pages infos 56216 (0.064%)  arp-flag page infos 2497880 (2.857%) variable size records 84801672 (96.985%)   line count around nodes2847844 (3.257%)   node region IDs 2112451 (2.416%)   arp-flags 79841370(91.312%)    code trivial 000 . . . 000 1689322 (1.932%)    code trivial111 . . . 111 1826696 (2.089%)    code found in history 1668053 (1.908%)   not found in history 74657299 (85.383%)     code not found in history1463183 (1.673%)     negate bit 607717 (0.695%)     blocks 72586399(83.015%)

All sizes are in bits. Total map size is 87,437,736 bits (10,929,717bytes).

The indentation reflects the hierarchy. The variable size recordinformation are by far the largest piece of information (96.975% of mapsize). In the variable size records, the sub items (indented) gives moredetails. The bit vectors are by far the biggest piece of information tostore in variable size records (91.312%). And in the bit vectors,storing the non-trivial bit vectors not yet encountered in historyconstitutes the biggest portion of the map (83.015%).

Statistics on Huffman Trees

This section gives statistics for Huffman trees when encoding Benelux in255 regions (i.e. for the map data shown above).

Huffman Tree of the Number of Road Segments Around Each Nodes

--- [Huffman trees: NrLines] --- bits: 1 value: 3 code 0 bits: 2 value:2 code 10 bits: 3 value: 1 code 110 bits: 4 value: 4 code 1110 bits: 5value: 5 code 11110 bits: 6 value: 6 code 111110 bits: 7 value: 7 code1111110 bits: 7 value: 8 code 1111111

Most nodes have 3 attached road segments, but in 2nd and 3rd position inthe Huffman tree we find nodes with 2 and 1 attached road segments(which are not decision nodes).

Huffman Tree of Non-Trivial Bit Vector Blocks

This is the biggest Huffman tree since storing blocks of trivial bitvectors is the biggest map size contributor by far (83.015% in theexample of Benelux 255 region).

--- [Huffman trees: NonTrivialArpFlagBlock] --- bits: 1 value: 0 code 0bits: 6 value: 1 code 100000 bits: 6 value: 2 code 100001 bits: 6 value:4 code 100010 bits: 6 value: 8 code 100011 bits: 6 value: 16 code 100100bits: 6 value: 32 code 100101 bits: 6 value: 64 code 100110 bits: 6value: 512 code 100111 bits: 6 value: 1024 code 101000 bits: 7 value:128 code 1010010 bits: 7 value: 256 code 1010011 bits: 7 value: 384 code1010100 bits: 8 value: 5 code 10101010 . . . snip, too large . . . bits:24 value: 1534 code 111111111111111111111011 bits: 24 value: 1717 code111111111111111111111100 bits: 24 value: 1741 code111111111111111111111101 bits: 24 value: 1830 code111111111111111111111110 bits: 24 value: 1973 code111111111111111111111111

Storing a block made of all 0 is the most frequent pattern and areencoded in only 1 bit according the above Huffman tree (which means 50%or more of blocks encode value 0, even though trivial bit vectors 000 .. . 000 are not encoded by blocks). This is because most non-trivial bitvector contains either

-   -   mostly 0s (and a few 1s)    -   or mostly 1s (and a few 0s)

The encoding scheme negates (˜) bit vectors containing mostly is so inthe end, encoding blocks of bit vectors mostly encodes blocks containing000 . . . 000 in 1 bit only. The next most frequent blocks are blockswhere only 1 bit is set (1, 2, 4, 8, 16, 32, 64 . . . ). They have moreor less the same frequencies hence same (or almost the same) number ofbits.

Huffman Trees of Local Region IDs

Since list of regions are stored by frequency in each page, we can seethat storing local region ID 0 takes less bits (in fact only 1 bit) thanother location region IDs. The different Huffman trees corresponds topages with 3 regions, 4 regions, 5 regions, etc.

--- [Huffman trees: Regions_0] --- bits: 1 value: 0 code 0 bits: 2value: 1 code 10 bits: 2 value: 2 code 11 --- [Huffman trees: Regions_1]--- bits: 1 value: 0 code 0 bits: 2 value: 1 code 10 bits: 3 value: 2code 110 bits: 3 value: 3 code 111 --- [Huffman trees: Regions_2] ---bits: 1 value: 0 code 0 bits: 2 value: 1 code 10 bits: 3 value: 2 code110 bits: 4 value: 3 code 1110 bits: 4 value: 4 code 1111 --- [Huffmantrees: Regions_3] --- bits: 1 value: 0 code 0 bits: 2 value: 1 code 10bits: 3 value: 2 code 110 bits: 4 value: 3 code 1110 bits: 5 value: 4code 11110 bits: 5 value: 5 code 11111 . . . snip . . .Huffman Trees of Bit Vector History Codes Code 0 (meaning trivial bitvector 000 . . . 000) is the most frequent (and encoded in 1 bit only inmost cases). Code 1 (trivial bit vector 111 . . . 111 is then the nextmost frequent (and encoded in 1 bits only). The next most frequent code(2) is for non-trivial bit vector encoded by blocks. The other codes(>2) for bit vector found in history.

--- [Huffman trees: ArpFlag_0] --- bits: 1 value: 0 code 0 bits: 2value: 1 code 10 bits: 2 value: 2 code 11 --- [Huffman trees: ArpFlag_1]--- bits: 1 value: 0 code 0 bits: 2 value: 1 code 10 bits: 3 value: 2code 110 bits: 3 value: 3 code 111 --- [Huffman trees: ArpFlag_2] ---bits: 1 value: 0 code 0 bits: 2 value: 1 code 10 bits: 3 value: 2 code110 bits: 4 value: 3 code 1110 bits: 4 value: 4 code 1111 --- [Huffmantrees: ArpFlag_3] --- bits: 1 value: 0 code 0 bits: 2 value: 1 code 10bits: 3 value: 2 code 110 bits: 4 value: 3 code 1110 bits: 5 value: 4code 11110 bits: 5 value: 5 code 11111 --- [Huffman trees: ArpFlag_4]--- bits: 1 value: 0 code 0 bits: 2 value: 1 code 10 bits: 3 value: 2code 110 bits: 4 value: 3 code 1110 bits: 5 value: 4 code 11110 bits: 6value: 5 code 111110 bits: 6 value: 6 code 111111 --- [Huffman trees:ArpFlag_5] --- bits: 2 value: 0 code 00 bits: 2 value: 1 code 01 bits: 2value: 2 code 10 bits: 4 value: 3 code 1100 bits: 4 value: 4 code 1101bits: 4 value: 5 code 1110 bits: 5 value: 6 code 11110 bits: 5 value: 7code 11111 . . . snip . . .Influence of Input Parameters on Map Size

There are a number of input parameters which control the file formatshown in FIG. 8 and which can influence map size. Tweaking theparameters can be a trade-off between map size and memory usage or speedof decompression depending on parameters.

Embodiments of the invention may use the following input parameters:

-   -   region page size    -   bit vector page size    -   bit vector block size    -   bit vector Huffman codec count    -   region Huffman codec count        Influence of Bit Vector Block Size

value map size (bits) 4 35548192 5 33648792 6 32290344 7 30853616 831103200 9 30436696 (default) 10 30051792 11 29266784 12 28934696

Increasing the Huffman block size for the bit vectors improve mapcompression. The higher the block size, the better the compression. Butincreasing block size comes at the price of requiring more memory tostore a bigger Huffman tree of 2^n values. The above table illustratesthis.

Influence of this parameter is expected to become more significant whenwe introduce the optimization to remap region IDs per source region:this optimization will hopefully result in significant maps sizereduction when using large bit vector block size.

Influence of Bit Vector Page Size

value map size (bits) 2{circumflex over ( )}1 55563944 2{circumflex over( )}2 42502936 2{circumflex over ( )}3 34898840 2{circumflex over ( )}430436696 (default) 2{circumflex over ( )}5 27389952 2{circumflex over( )}6 25165032 2{circumflex over ( )}7 23635936

Increasing page size helps to compress maps better. But big pagesunfortunately slow decompression of the data in the file format byrouting methods, since accessing bit vector of a random road segmentrequires to decode all road segments in page. The above tableillustrates this.

Influence of Bit Vector Huffman Codec Count

value map size (bits) 1 30866920 2 30748024 3 30634168 5 30504504 730467944 9 30436696 (default) 11 30423688

Increasing the number of bit-vector Huffman codec helps to increasecompression slightly and this is illustrated in the above table. Thereis almost no drawback to increasing the value since those Huffman treesare small anyway. Increasing beyond 9 Huffman trees (default value) doesnot give any significant improvement. Increasing this parameter might bemore effective with larger bit vector pages.

Coalescing & Reordering Bits in Bit Vectors

Bit vectors have patterns. Those patterns differ significantly for eachsource region (i.e. region of the node where bit vector is stored). Thenumber of bits to store N-bits bit vectors can be reduced by storingsmall translation tables for each source region. These tables perform 2functions further described in this section:

-   -   bit coalescing    -   bit reordering

The idea can be understood intuitively as follows: when in Spain, it isclear that a road segment which leads to Sweden (bit=1 for destinationregion Sweden) is most likely to also lead to Norway (i.e. bit fordestination Norway is then also 1). If another road segment does notlead to Sweden (bit=0), then it also does not lead to Norway in mostcases. So when in Spain, the values of the bit vector bits for thedestination regions Sweden and Norway are almost always equal. In fact,they are even always strictly equal for many destination regions. Whichbits are well correlated with which bit depends greatly on the fromregion.

When in Finland for example, bits for destination region Norway andSweden are far less correlated. On the other hand, in Finland, bits fordestination region Spain and Portugal are likely to be 100% correlated(or at least very close to 100%).

Bit coalescing exploits the property that some bits are always equal(fully correlated). Those bits can be coalesced into a single bit.Coalescing bit reduces the number of bits to encode in each region.

Bit reordering exploits the property than some bits are fairly wellcorrelated (but not 100% correlated) in order to shuffle bits in such away as to optimize Huffman encoding of bit vectors (and/or reduce sizeof Huffman trees).

Before computing tables to coalesce bits and reorder bits, thecorrelations of all pairs of bits in all from-regions are calculated.The number of distinct pairs is:C(N,2)=N!/(2!*(N−2)!)=N*(N−1)/2. . . where N is the number of regions. This number is thus fairly highwhen the number of regions is high. Computing all bit correlations isthe slowest part of the method to generate the file format shown in FIG.8. The complexity of the method is n*N*N where n is the number of bitvectors and N is the number of regions. For each pair of bits (i.e. pairof distinct columns in bit vectors) in each region, we compute atri-dimensional table:bitCorrelation[fromRegionId][bitI][bitJ].

Each entry in table contains a struct of 4 fields which counts:

-   -   the number of times bitI=0 and bitJ=0 in all bit vectors of        fromRegionId    -   the number of times bitI=0 and bitJ=1 in all bit vectors of        fromRegionId    -   the number of times bitI=1 and bitJ=0 in all bit vectors of        fromRegionId    -   the number of times bitI=1 and bitJ=1 in all bit vectors of        fromRegionId

Although expensive in terms of processor time (and therefore slow) tocompute, this process can be easily parallelized since computing bitcorrelations for each from-region is completely independent from otherfrom-regions.

Embodiments of the present invention use multi-threading to speed upcomputation of correlation of all bits to efficiently use SMP (SymmetricMultiprocssing) machines. In one system, a 1-CPU machine computing bitcorrelation of Benelux with 300 regions takes about 8 minutes. Butparallelism scales well and when enabling threads and using the 4 CPUscomputing bit correlation then takes 2 minutes (4 times less).

Bit Coalescing

When several bits are fully correlated (i.e. always all 0 or all 1), wecan coalesce them into only 1 bit without loosing any information.Referring to a set of bits which are fully correlated in a given regionas a ‘group’ then bit vectors of a given region are made of severalgroups. If N-bit bit vectors are made of n groups, then encoding N-bitbit vectors uses n-bits+a small table to indicate which bits areequivalent in each region.

Such bit coalescing has the advantage that size of the resultant file isreduced in a lossless manner. This advantage is likely to be increasedas the number of regions increases since more bits are likely to becoalesced. So map size increases in a sub-linear way with number ofregions.

In one embodiment the following data was obtained:

maximum minimum average number number of groups number of groups ofgroups Benelux 255 regions 12 84 152 Benelux 300 regions 13 90.017 163

As such, in the Benelux example having 255 regions there is at least 1region which has only 12 groups (i.e. requires only 12 bits to encodeits 255 bits bit vectors (i.e. the bit vector is the same length as thenumber of regions) even before Huffman encoding (and thus even lessafter Huffman encoding).

On average, regions require 84 bits for Benelux 255 regions. In thisexample, the worst region requires 152 bits (152 groups) before Huffmanencoding.

As another example and taking region Id=3 in the above 255 regionBenelux example which has the following 18 groups as taken from theencoded data.

regionId = (B) has (18) groups: #1 ( 0 ) #1 ( 1 ) #1 ( 2 ) #141 ( 3 4 57 9 11 12 15 16 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 36 37 38 3940 42 43 44 45 46 50 51 59 60 62 63 66 67 69 71 72 73 74 :75 76 80 81 8283 84 86 88 89 90 95 96 97 98 100 101 102 103 104 105 106 108 110 112113 119 120 123 127 129 130 133 135 136 139 142 143 147 148: 149 150 151154 155 156 157 159 160 165 166 167 171 172 173 174 176 177 178 179 181182 183 190 192 200 203 205 207 210 211 212 213 214 215 218: 219 220 221222 226 227 229 235 237 241 242 243 244 245 247 249 250 252 ) #1 ( 6 )#1 ( 9 ) #1 ( 10 ) #30 ( 13 14 35 48 49 57 68 85 93 109 115 117 118 120131 134 138 153 159 164 168 169 187 189 195 209 217 224 238 239 ) #59 (17 18 47 53 54 56 65 91 92 99 107 114 116 121 124 125 126 132 137 140141 144 145 146 152 161 162 163 170 175 180 184 185 186 191 193 194: 196198 199 201 202 204 206 208 216 223 223 228 230 231 232 233 234 236 240246 248 251 ) #1 ( 34 ) #5 ( 41 78 79 111 197 ) #3 ( 52 77 87 ) #1 ( 55) #3 ( 54 61 94 ) #1 ( 64 ) #1 ( 70 ) #1 ( 132 ) #1 ( 188 )

Each line represents a group (18 groups for regionId=3). The numbers inparentheses are bit indices which coalesced in each group. The numberafter # is the number of bits in each group.

In this example, 1 group is very large and contains as many as 141regions. This is not unusual. In general, regions on the border of themap coalesce more bits than region in the middle of the map.

In this example, the number of bits has been reduced on average by afactor˜3 (˜=255/84). Of course that does not mean that map size isreduced by a factor 3 since the remaining bits to encode have moreentropy than original bits (so are more difficult to encoder withHuffman blocks). But bit coalescing bits may still reduce map size,perhaps significantly.

When coalescing bits in each region, bit vectors in each region havedifferent number of bits as result (hut identical number of hits for hitvectors of a given from-region) as illustrated in FIG. 12. The shadingillustrates the from-region ID of each bit-vector. The y axis expressesthe sequential order of the segments. For instance, the block at the topmight represent 1043 lines, the next block might represent 507 lines,etc.

Once table bitCorrelation has been computed, identifying groups of fullycorrelated bits is fairly easy and fast. All pairs of bits where we findno 01 or 10 patterns are fully correlated and can be coalesced into 1bit.

To give a further example of bit coalescing, the table below gives anexample of 6 bit vectors, each of 15 bits. These have not beencoalesced.

  100111101111100 000001101110100 011001010010111 111110010001011011000010000011 000000101100000 . . .

These 15-bit vectors can be coalesced into only 4 groups—hence 4 bitsper bit vector before Huffman encoding. This is shown in the followingtable:

1 + 2 + 5 + 4 + 1 2 3 4 5 6 7 8 9 10 11 3 + 9 11 7 8 + 10 1 00 11 1 1 011 1 1 1 00 → 1 0 1 1 0 00 00 1 1 0 11 1 0 1 00 → 0 0 1 1 0 11 00 1 0 100 1 0 1 11 → 0 1 0 1 1 11 11 0 0 1 00 0 1 0 11 → 1 1 0 0 0 11 00 0 0 100 0 0 0 11 → 0 1 0 0 0 00 00 0 1 0 11 0 0 0 00 → 0 0 1 0

The heading of the right hand portion of the table shows which bits the4-bit coalesced vector in the left hand portion of the table. Toclarify, the first bit of the 4-bit coalesced vector represents the 1st,3rd and 9th columns of the left hand portion. As such, since the 1st,3rd and 9th bits of the left hand portion (i.e. the 15-bit originalvector) are always the same in the above example, they may berepresented by the 1st column of the right hand side of the above table.

Thus, in summary a table of concordance between the left and right handsides is as follows:

original bit coalesced bit 0 0 1 1 2 1 3 0 4 0 5 3 6 2 7 1 8 2 9 2 10 311 0 12 3 13 1 14 1

What coalescing hits effectively does, is to group nearby destinationregions and destination regions in the same angle sector from thefrom-region as illustrated in FIGS. 13a and 13 b.

The shading in FIGS. 13a and 13b indicate groups of regions which arecoalesced together. The 2 Figures (i.e. FIGS. 13a and 13b ) show thesame regions coalesced from the point of view of 2 differentfrom-regions: A and B. Which region coalesced together depends on theregion ID of the from node as shown by the Figure. In these Figures, the8 regions are coalesced into 4 groups. Coalescing bits is different fromthe point of view of from-region A or from-region B in these Figures.Notice how the vertical striped region (1300) are coalesced because theyare in the same direction when seen from the from-region A.

This is further exemplified in FIG. 14 which illustrates that coalescingbits groups nearby destination regions and destination regions in +/−the same angle sector, from each from-region point of view.

After coalescing bits, the number of bits to encode for bit vectorsdiffer for each region. In the case of Benelux 255 regions for example,the number of bits bit vector for each region is:

from region -> coalesced bits 1 -> 57 2 -> 93 3 -> 18 4 -> 12 5 -> 63 6-> 75 . . . snip . . . 251 -> 21 252 -> 46 253 -> 117 254 -> 80

The method is exact (it is not a heuristic). It thus finds the idealnumber of groups of bits.

In some embodiments, coalescing bits is implemented in a lossless way:region are only coalesced when they always have the same bits. Rut inother embodiments, this may be extended to make it lossy; i.e. such thatfull recovery of the original data is not possible. Such lossyembodiments may introduce a threshold (i.e. a measure of closeness): ifa pair of bits differ by less than X times, then we could coalesce thebits if replacing one or more 0's with a 1 in some of the bit vectorsallowing those bit vectors to be coalesced. Thus, in some embodimentssuch coalescence is performed on bits which are substantiallycorrelated.

An example of such a lossy coalescence would be to coalesce 0000001100with 0000001110. An advantage of such an approach is that there isbetter compression of the data but a disadvantage is that further roadsegments will be assessed by routing methods using the bit vectors sinceextra l's will indicate that a road segment is part of a fastest route.

In the case of lossless coalescing, the threshold is 0. Increasing thethreshold would allow to coalesce further regions, at the cost ofintroducing a few bits 1 in the bit vectors. But if the threshold iskept low, it would have almost no impact on the speed at which routingmay be performed using the data format. For example, if 2 bits arealmost always identical in thousands of bit vectors, except for say only1 bit vector, it my be acceptable to alter this unique bit vector whereit differs to make it possible to coalesce more bits. The higher thethreshold, the more map compression we can expect.

Bit Reordering

In some embodiments, once bits have been coalesced as described above,bits may be reordered. Reordering bits does not reduce the number ofbits to encode (before Huffman encoding) but helps to make Huffmanencoding more efficient, hence reducing map size and also can help toreduce the number of distinct codes in bit vector Huffman codes, hencereducing memory requirement for Huffman trees.

Unlike bit coalescing, bit reordering is a heuristic method so it findsa good reordering but it may not find the best one.

Bit vectors are encoded by blocks. Block size is customizable and storedin the map header 800. In the explanation given below, and as anexample, the block size is set to 11 bits. The number of bits in bitvectors may not be divisible by 11, so the last block may be smallerthan 11 bits. The last block uses a different Huffman tree than the onefor full blocks of 11 bits. Encoding each bit vectors thus encodes:

-   -   several full blocks using a Huffman code for 11 bit-blocks (in        this example)    -   1 last block which may another Huffman code when less than 11        bits remain.

The following picture depicts the bits to Huffman encode by blocks withbit vectors in 2 regions (which have different number of bits aftercoalescing):

Having Huffman trees for each region would likely be too expensive inmemory. So in some embodiments, the same Huffman tree is shared for allregions. Since correlated bits are different in each region, it pays-offto reorder bits in each region, so that the correlated bits are putsystematically at the same positions in all regions. So sharing ofHuffman tree across all regions becomes more efficient.

The table to reorder bits for each region is stored in map data. Notethat we do not need to encode a separate table to coalesce bit and tableto reorder bit but we can instead encode only 1 table which is thecomposition of both transformations (coalescing+reordering).

The method to reorder bits in full blocks proceeds as follows: for eachregion, find the pair of bits most correlated. Since fully correlatedbits have already been coalesced, none of the remaining bit are fullycorrelated. However, some pair of bits are far more correlated thanother. The most correlated pair of bits (a, b) are remapped to bit #0and #1 in the first full block:

As a result of grouping pairs of bits most correlated, Huffman trees offull blocks have less distinct codes (which has the advantage of usingless memory to store the data) and the statistics are more skewed(making Huffman encoding more efficient). Rather than containing randomsequences of hits, the first 2 bits for example contain in the vastmajority of the cases either 00 or 11 but almost never 10 or 01 (samefor other bits). Without reordering bits, the first 2 bits would containall kind of patterns 00, 01, 10, 11.

After remapping the first 2 hits, method then finds the next mostcorrelated (c, d) pair of hits and remap them to store them in the first2 bits of the second block:

Then method finds again the next most correlated (e, f) pair of bits andremap them to store them in the first 2 bits of the third block:

When reaching the last full block, the method goes back to the firstfull block and remaps the next most correlated pair of bits (g, h). Ifseveral pairs have same correlation, a tie breaker selects the pair mostcorrelated with the previous pair in the same block (i.e. pair mostcorrelated with (a, b)):

The algorithm method proceeds as above until all pair of hit in fullblocks have been remapped:

In this example, since block size has an odd number of bits (11 bits) anon-remapped bit still exists in each full block. The method then findsthe bit most correlated with ‘z’ and stores it in the first block. Thenfinds the bit most correlated with B and stores it in the second block,etc. until all full blocks are remapped:

At this point, all bits are remapped in full blocks. The method thenremaps bits in the last block trying to group the pair of bits mostcorrelated as was done for the full blocks. Reordering bits in the lastblock can help to reduce map size but it does not help as much asreordering bits in the full blocks for 2 reasons:

-   -   Full blocks are more important. In this example, each code uses        3 Huffman codes for full blocks whereas it uses only 1 Huffman        code for the last block, so it is normal that full blocks        contribute more to the overall map size than the last incomplete        last block and it is more useful to optimize Huffman encoding of        full blocks.    -   Since we already picked all the most correlated bits to remap        them in the full blocks, the bits left to remap in the last        block are less correlated. So entropy of bits in the last block        is thus higher than for bits in the full blocks. In other words,        Huffman encoding of the last block is not as efficient as        Huffman encoding of the full blocks.

It should be remembered that the same Huffman tree is used for all fullblocks of all regions.

Encoding the bit vector in the above example thus encodes with the sameHuffman codes all the full blocks and finally encodes the last blockwith a different Huffman codec:

The reason for the method to remap first bits of each block (rather thanremapping all bits in first block before jumping to second block) shouldbe clearer when seeing the above figure. Since the same codec is usedfor all full blocks, it is desirable to have all codes for all blocks asidentical as possible. If we were to remap all bits in first block, thenall bits in second block (etc), then each block would have quitedifferent patterns: first blocks would have the most correlated bits,second block would have less correlated bits, third block would haveeven less correlated bits, etc. It would be possible to create severalHuffman codec for each column of the full blocks but that is believed tobe too expensive in memory. The method so-far outlined works well whilesharing the same Huffman codec for all full blocks.

Possible Other Optimizations

This section describes optimizations that may be used in furtherembodiments in order to compress the data further.

Pages of Pages

The page info stores a delta field which is used to find the beginningoffset of each bit vector page. The delta field is stored using a linearinterpolator of the offset. But the offsets are not very linear becausebit vectors around small node ID's (level 0, motorways) require morebits than bit vectors around high node ID's (level 5, destinationroads). The graph of FIG. 15 shows the delta field for the map ofBenelux with 300 regions.

Encoding of bit vector page info is not as advantageous as may bedesired because the interpolator does not precisely predicts the actualoffset. By improving the interpolator, it would be possible to improvethe encoding of the bit vector page info table to make it moreefficient.

Some embodiments of the invention may use bit vector pages (and possiblyregion pages) having 2 levels rather than only 1 level. The pages of2^(n) nodes to group the data (let's call them subpages) can be groupedinto pages of 2^(N) subpages.

As such, the linear interpolation parameters would be stored per pagerather than globally (in header). For example, index level 2 might group2⁴=16 nodes as earlier in subpages, and index 1 might group 2¹⁰=1023 ofthose subpages in pages. The linear interpolation then happens for1024*16=16K nodes rather than on the entire node count (50,000,000 nodesin a map of Europe and Russia) so the linear interpolation of variablesize offsets becomes much more accurate and the delta fields in index2are thus smaller.

The size of the extra index1 is small if pages are large (small enoughto fit in memory). Being able to fit within a memory of a device isadvantageous since it should not slow down routing using the data.Rather than storing the average page size in header, the average pagesize could then be stored for every entry in the index1 table.

Interleave Bit Vector Pages

As described above, the interpolator for page offset is not accuratebecause bit vectors are different for important roads (many non trivialflags) and minor roads (many trivial flags). One simple way to make theinterpolator more linear is to interleave pages of different networklevels and this may be used in embodiments of the invention.

The file described in the above embodiments stores the following pages:

-   -   #0    -   #1    -   #2    -   #3    -   #4    -   . . .    -   #n−3    -   #n−2    -   #n−1

In other embodiments which may be more efficient it is possible to storein an interleaved manner as follows:

-   -   #0    -   #n−1    -   #1    -   #n−2    -   #2    -   #n−3    -   #3    -   #n−4    -   . . .

To access page #x (for example by a route planning application) the pageis accessed by loading page #x′ where:

-   -   x′=2*x (when x is even)    -   x′=2*(x−(n−1)) (when x is odd)

Such an embodiment should be advantageous since it will reduce size ofindexing by several bits per page. However, data may be less wellgrouped for caching which may slow down data access (less hits in filesystem cache).

Do not Store Region IDs for all Nodes

Region IDs does not need to be stored for nodes at dead ends and nodeswith 2 attached road segments. These nodes can be ignored for routing.Going to one of these nodes can be transformed into going to theirneighbour decision nodes.

Store Extra Information at Page Level and or at Node Level

Looking at map data, there are lots of bit vector pages which onlycontain trivial bit vectors 000 . . . 000 or 111 . . . 111. Someembodiments may store 1 bit for each page to mark those pages, thenstoring bit vectors in those pages can be more efficient since we onlyneed a single bit for each bit vector to indicate whether it's 000 . . .000 or 111 . . . 111. Not only it will reduce size of pages which onlycontain trivial bit vectors, but it will also make Huffman tree of bitvector codes better optimized for pages which have non-trivial bitvectors (the number of bits to indicate non trivial vectors will bereduced since the frequency of those codes will significantly increasein percentage). In the finer network level (eg level 3), most of thepages only contain trivial bit vectors so there may be only 1 bit vectorper page in about half of the pages.

Store Bit Vectors Only at Decision Nodes

As discussed above, some embodiments might not store bit vectors fornodes with 1 or 2 attached road segments. However, other embodiments maybe more aggressive and generalize the idea to only store bit vectorsaround decision nodes.

Concepts of decision node and decision road segment are introducedbecause they can be advantageous in encoding of map data: hit vectors donot need to be encoded for non-decision road segments as is nowdiscussed.

-   -   A decision node is node where there is an incoming road segment        for routing such that there are multiple choices to leave the        node (without making a U-turn).    -   A non-decision node is a node which is not a decision node. So        regardless of the where routing comes from, there is always only        one way out to leave the node.    -   A decision road segment is a road segment which is legal in        order to leave a decision-node.    -   A non-decision road segment is a road segment which is not a        decision road segment.

All decision road segment s are thus around decision nodes. But not allroad segment s around decision nodes are decision road segment. All roadsegments around non-decision nodes are non-decision road segments.

Bit vectors will be encoded only for decision road segments. Bit vectorsare implicit (000 . . . 000 or 111 . . . 111) for non decision-roadsegments since routing techniques using the data can make adetermination from information already present in road segments.

How to determine whether a node is a decision node? The criterion we canbe reduced to:isDecisonNode=(lineCount>=3)&&(lineGoingOutCount>=2)Where:

-   -   lineCount: is the total number of lines attached to node        ignoring non routable line types (railways, reference lines),        ignoring lines closed in both directions and ignoring no-through        roads (residential areas).    -   lineGoingOutCount: is the number of lines attached to a node        which are legal take for leaving the node.

Whether or not it is legal to take a road segment to leave the nodedepends on road segment attributes:

-   -   road segment type (railways & reference lines are always        illegal)    -   forward/backward flow of way (stored in road segment flags)    -   no-through attribute in road segment flags (no-through road        segment s do not have any bit vectors)

In some embodiments ignoring non decision road segments can discardroughly 40% of the road segments. It has been found that this percentageis quite consistent regardless of the map. Avoiding to encoding of 40%of bit vectors is advantageous but it saves less than 40% of the mapsize, since it mostly removes trivial bit vectors.

Removal of bit vectors around nodes with less than 3 attached roadsegments (dummy nodes) removes non-trivial bit vectors, so a map sizesaving for this category of non-decision road segments can be biggerthan for the non-decision road segments. On the other hand, filteringrequires a decoder (such as a routing method using the map) to decoderoad segment types and road segment flags of lines and apply a logic onthem in order to figure out bit vectors that are implicit, which mayslow down the process.

In theory embodiments could also look at maneuvers (i.e. turnrestriction) to decide whether a road segment going out is legal, butsuch a technique adds complexity. Ignoring manoeuvre means thatembodiment may encode more bit vectors than strictly necessary but asimplification in the method is achieved.

Example of Non Decision Nodesa--<->- -b--<->- -c

In this example, (b) is attached to 2 road segments navigable in bothdirections. (b) is not a decision node, because there are <=2 attachedroad segments.

So bit vectors of both road segments leaving node (b) will not beencoded. Decoder can implicitly set them to 111 . . . 111.

Arrows > in this example show the legal direction of flow. (b) is not adecision node, because there is only one way out. So none of the roadsegments around (b) need bit vectors.

Bit vectors for the road segment (b)->(c) leaving node (b) are notencoded, it will implicitly be 111 . . . 111. Bit vectors for illegalroad segments leaving (b) are not encoded either, they will implicitlybe 000 . . . 000.

Examples of Decision Nodes

(b) is a decision node because when coming from (d), there is a choice:routing can continue towards (a) or toward (c).

Notice that in this example, when coming from (a), there is no choice:routing can only continue toward (c). But node (b) is still a decisionnode because there is at least a choice when coming from (d) so bitvectors should be stored for the 2 decision road segments around node(b).

Bit vectors are stored for road segment (b)->(a) and road segment(b)->(a) since they are decision road segments.

A bit vector is not stored for road segment (b) (d) since this roadsegment is illegal to take according to backward/forward flow oftraffic. It is implicitly 000 . . . 000.

OR-Ing Bit Vectors

Let's suppose that a node has 3 attached road segments and that thefirst 2 decoded road segments have the following bit vectors:

-   -   00000000000000000000    -   00000000000000000000

Then the third bit vector does not need to be encoded because it canonly be:

-   -   11111111111111111111

This can only work if bit vectors of road segments around node a happento be in this order: all bit vectors 000 . . . 000 and the last one is111 . . . 111. In practice it seems to happen fairly frequently in thefiner level (eg level 3) network (which is where most of the roadsegments are).

Taking the first 2 bit vectors to be:

-   -   00000000000000000110    -   00000000000000000010

Then the third bit vector has can only have all its bits set to 1 except2 bits which are unknown and need to be somehow encoded.

-   -   11111111111111111??1

Since in the above example, most of the bits are already known, itshould be possible to use this information to encode the 2 unknown bitsmore efficiently than encoding the whole bit vector. Thus, in thisexample, it is only necessary to encode 2 bits.

A possible fast decoding scheme using this property would be to computea bit-mask of all decoded bit vectors in the road segments of thecurrent nodes by OR ing all previous bit vectors in the road segment.Using the same example as earlier, if a node has 3 attached roadsegments and if the previous 2 road segments have the following hitvectors:

-   -   00000000000000000110    -   00000000000000000010        . . . then the OR bit mask is:    -   00000000000000000110

Taking the 3rd and last bit vector to encode around the node as:

-   -   11111111111111111001

Instead of encoding the Huffman code of 11111111111111111001 which maybe rare, the encoder is free to encode any other code (otherCode) aslong as:value_to_encode=−bitMask|otherCode

In this example, otherCode=0000000000000*0000000 qualifies since:value_to_encode=11111111111111111001=−0000000000000*0000110|0000000000000*0000000

Encoding 00000000000000000000 is much more efficient than encoding11111111111111111001 since 00000000000000000000 is far more frequent.Decoding is fast, since decoding only needs to compute the bitmask (oroperation) whenever it decodes a bit vector and apply the bitmask to thelast decoded bit vector:actual bit vector=bitmask & decoded bitvector=−00000000000000000110&00000000000000000000=11111111111111111001

This optimization works well if road segments around nodes are stored insuch a was so as to have the one with most 1 in the bit vector at an endregion. However, this can prove difficult:

-   -   sorting road segments around a node is performed before        computing bit vectors (unless we use the bit vector information        a posteriori to re-encode)    -   road segments are already sorted by road names. It is possible        to sort road segments around nodes when road names are        identified.        Using Network Levels

In addition to the levels of the regions, road segments within the mapdata are categorised according to a road segment level. There should bea strong correlation between bit vectors and road segment network levelsaround from-nodes: routing to another region will generally prefer totake the high level road segment network eg motorways, or the like. Themost important road segment network level is probably the motorway levelwhich may be level 1.

The following example depicts an intersection with road segments atdifferent network levels:

The bit patterns are likely to be as follows:

2 1 ???????????? 2 3 ???????????? 3 4 000000000000Not Storing Hit Vectors for Nodes at Unimportant Road Segment NetworkLevels

Routing almost never go through unimportant road segment network levels,such as network level 5, except close to the destination or startingpoint. Thus, it is possible not to store bit vectors at level 5 and assuch, there should be a minimal impact on routing, even though thenumber of road segments at level 5 is large. Routing in most cases willonly explore few road segments at the most unimportant network level atthe start or the end of a route since it will quickly reach some moreimportant road segment network levels, and the search acceleration dataon those nodes will almost always tell the router to skip a navigationsegment that goes hack to the most unimportant network level and to usea navigation segment that leads to or stays on the more importantnetwork levels.

This is true at the most important network level since that networklevel is used when the destination is still far away.

In addition to dropping bit vectors at the most unimportant road segment(eg level 5), we could also not encode region IDs at that network.

Transform a Few 0s into 1s in Bit Vectors

This is also a lossy compression scheme.

If a bit vector only contains only one 0 (or possibly less than a smallthreshold), then it may be possible to transform it into 1 if it resultsin (i.e. setting that road segment to be part of a fastest route):

-   -   a trivial bit vector 111 . . . 111 (since trivial bit vector are        encoded in a more compact way than non-trivial bit vector)    -   or a bit vector already found in the history of the current bit        vector page (since those are also encoded more efficiently)

Transforming 0s into 1s in bit vector does not affect the routingoutcome, it only makes it slower by having routing consider more roadsegments (because they are now set to be part of the fastest route).However, some embodiments of the invention may employ thismethod—particularly if the map saving is large with a small performancehit in terms of routing speed.

Routing

FIG. 15 shows a map 1600 covering an area and having a start node 1602and a destination node 1604 together with a plurality of road segmentsthat have been explored by the prior art A* search method. The selectedroute is shown by the dotted line 1606.

FIG. 16 shows a map 1650 covering the same area as the map of FIG. 15and also showing the same start node 1602 and destination node 1604. TheFigure also highlights the roads that were explored using an embodimentof the present invention which utilised the same road network and samecriterion as used to generate the route of FIG. 15 (eg both aretravelling by car, wishing to used speed as the cost function tominimise, etc.). The route selected by the method is again shown withthe dotted line 1606 and it should be noted that the line is the same asthat calculated in FIG. 15. As such, it is noted that the routescalculated by embodiments of the current invention may be so-calledmathematically exact and find the best/optimal route with respect to thegiven cost model that was selected to be minimised. Thus, it will beapparent that the road-segments explored by the embodiment of thecurrent invention is significantly less when compared to the prior art.As such, the method of the embodiment of the invention is quicker, andgenerally significantly quicker, than the prior art A* method.

It should also be noted that as the route 1606 approaches thedestination 1604 more routes are explored when compared to thebeginning; i.e. when the route 1606 proceeds beyond the point 1652 roadsare explored other than the lowest cost route. One explanation of thisis that the method has switched from the level 0 region to the level 1region at point 1652. It will further be seen that further road segmentsare explored in the vicinity of the destination 1604. Again, this can beexplained by noting the route planning method will switch from level 1to level 2 in this vicinity.

Thus, when routing at long range, there will typically be only onefastest route. However, as the method switches to a finer level (eg fromlevel 0 to 1) there may be more than one route which is marked as the‘lowest cost’ and therefore needs to be explored.

Once the map data has been created and the bit vectors calculated andstored, it can be used for calculating routes between two points.

FIG. 17 shows the prior art A* method in which a network is explored bya route planning application wherein a decision is made at a node as towhich road segment to explore further. In order to achieve this the costto travel to the next node is added to the estimated cost of moving fromthe next node to the goal. The path having the minimum cost from a givennode is then explored further. The method keeps a total of the cost thathas so far been incurred as the method proceeds and at each iterationthe minimum cost is considered.

For example, starting at node B, it can be seen that both nodes C and Dare 2 cost units away from B, the start node. However, from node D theestimated cost of reaching node F is 3 units and from node C theestimated cost of reaching node F is 5 units. Thus, the A* method wouldexplore the route to node D in preference to the route to node C sincethe cost to the next node plus estimated cost to goal is less for theroad segment to node D. (i.e. BC=2+5=7 whereas BD=2+3=5).

When considering route planning is performed using the hit vectors ofembodiments of the present invention, the bits for each road segment(i.e. column 704 of FIG. 7) identify which road segments are candidatesfor being part of a lowest cost route to a destination region. As such,the A* method described in relation to FIG. 17 is modified to that shownin FIG. 18.

Typically route planning is performed using the bit vectors as describedin relation to FIG. 18. However, some embodiments of the invention mayallow route planning to fall back to A* (or other prior art methods) invarious circumstances. Different embodiments may utilise any of thefollowing: bit vectors information is missing (thereby allowing thesystem to function even in the absence of the bit vectors); a costfunction is used; the routing other than the cost function for which thebit vectors were calculated (typically fastest route but not necessarilyso); a user specifies criteria different to those used to pre-calculatethe bit vectors (for example user wishes to avoid motorways); thevehicle type is different to that used for the pre-calculation of thebit vectors (eg. the user is on foot and not in a car); and the route isbelow a threshold length (eg the start and end points of the route arewithin the same region).

Two extra digits, 1800, 1801 are shown on FIG. 18 when compared to FIG.17. Additionally, regions are denoted on the Figure by the hashed lines1802 and 1804. The ‘1’ 1800 indicates that the road segment BD is partof one low cost route from node B to the region in which the goal nodeis situated (as described elsewhere there may be other low cost routesin addition). The ‘0’ 1801 indicates that the road segment BC is notpart of any low cost route from node B to the region in which the goalnode is situated.

As such, when starting from node A embodiments of the invention woulduse the A* outlined above to explore nodes from A. However, once node Bhad been reached there is no need to use the exploration further sincethere is an explicit notation that only the road segment BD is apossible part of the lowest cost route. As such, once the A* method hasbeen used and found the lowest cost route it will subsequently selectthe lowest cost route by looking at the relevant bits within the bitvectors.

However, the minimum cost data may identify more than one minimum costpath between a pair of the regions if different minimum cost paths existbetween the pair of regions at different times. Therefore, a routingbetween a start node and goal node (origin and destination) may findmore than one minimum cost path and have to decide between competingminimum cost paths, for example if both digits 1800 and 1801 for roadsegments BD and BC have a value “1” indicating that each road segment ispart of a minimum cost path at a certain time. In this embodiment, thebit vector does not identify the time at which each road segment is partof a minimum cost path. Accordingly, the routing algorithm carries out acost analysis for both possible minimum cost paths based on a time atwhich segments of the path are travelled. This time may be determinedfrom a time of departure from the origin/start node.

Associated with each segment is a speed profile, as shown in FIG. 10a ,of how the expected speed of travel through the segment varies withtime. From these speed profiles, the expected speed at the relevant timecan be determined and this can be used to determine the cost oftravelling along that road segment at that time. By summing up the costsof travelling the road segments of each minimum cost path, the cost foreach minimum cost path can be determined. The navigation device may thenselect for the route the minimum cost path having the lowest cost forthat time.

In order to perform the routing so far described, bit vector informationis obtained from the encoded side file described in relation to FIGS. 8to 10 using a decoding process.

The output of the pre-processing described above comprises:

-   -   an assignment of hierarchical regions to most of the nodes, and    -   an assignment of bit vectors to the outgoing road segments at        these nodes.        Map Loading        Consistency Checks

When map data is loaded, the set of side-files should be present in themap directory, otherwise the decoder will deactivate the searchacceleration data so that the route search is carried out without searchacceleration data. There are several checks which help to ensure dataintegrity, which are now listed.

The side-files follow a naming convention.

The number of levels is given by the number of side-files, but it isalso stored in the header of each side-file and equals the number ofside file.

Each side-file stores the number of regions at its respective level,which is the same as specified in the side-file names. Moreover, theside-files store the following information, which should be the same forall side-files:

-   -   the side-file version.    -   the number of nodes per “bit vector page” (explained below).    -   There are also checksums in each side-file which identify    -   the particular side-file set as a whole    -   the map as a whole.

These should be correct for the side-files associated for a givenelectronic map. If any of the above checks fails, the searchacceleration data feature will not be activated for this map.

Data Structures which are Loaded into Memory

The decoder reads the side-files in an external-memory implementation.This means that the contents of the bit vector side-files are not loadedentirely into memory, but only read as needed. However, some generaldata is loaded into memory at the beginning and held there as long asthe map is loaded.

Header Information

Each side-file starts with a header section, which contains the datadescribed in relation to FIGS. 8 to 10 above. This information is storedin memory for each side-file.

Huffman Tree Definitions

The side-files contain the definitions of several Huffman trees. EachHuffman tree definition gives the complete description of a particularHuffman encoding and is used later to decode a part of the side-filebitstream into the original data (i.e. to decode a sequence of bits froma side-file into a number or some other particular value). The followingHuffman tree definitions are read from each side-file and held inmemory.

-   -   A Huffman tree for decoding the number of road segments at each        node. (The encoded number of road segments can be smaller than        in the underlying map. Note than the decoder is independent of        the underlying map, i.e. it does not need to read the map.) This        Huffman tree is only stored in the level-0 side-file.    -   A Huffman tree for decoding the page code (explained below).    -   Several Huffman trees for decoding bit vector blocks. The number        of tree definitions is given by the regular bit vector block        length as stored in the side-file header; it equals the block        length minus one. (The entire bit string of bit vectors for a        road segment is split into blocks. If the length of the bit        vector bit string is not a multiple of the regular block length,        then the final block is shorter. There is one Huffman tree for        each block length from 2 up to the regular block length. No        Huffman tree is used for a block of length one, because this is        just a bit and is stored directly.)    -   Several Huffman trees for selecting the decoding method for bit        vectors. The number of these trees is specified in the header;        their use is explained below.        Neighbour Lists

At each level except the finest level, the side-file encodes neighbourlists. A neighbour list for a region at level k is a list of zero ormore level-(k+1) regions which are called neighbours of the level-kregion. The neighbour list section at the level-k side-file has twoparts.

-   -   The first part contains the number of neighbour regions for each        level-k subregion. For example (k=1), if there are 4000 regions        at the global level 0, and each global region is subdivided into        10 level-1 regions, then the level-1 side-file contains 4000*10        level-1 subregions. For each of these, the length of the        individual neighbour list (which consists of level-2 regions) is        given.    -   The second part contains the actual neighbour lists, whose        respective lengths are known from the first part. Each neighbour        list is a list of level-(k+1) subregions.

Thus, the neighbour lists specify for a given destination region regionslying the visibility area of that destination region. As such, anindicator is provided which identifies, to a navigation device using themap data, the extent of a visibility area. As such, route planning usingthe search acceleration data can identify whether further searchacceleration data is available to a destination region which can be usedto constrain the navigable segments which are explored, thus speeding upthe route planning.

Region Remap Table

The side-files store hit vectors in a compressed format eg by coalescingand reordering, etc. The side-file at level k has a region remap tablewhich is used to decompress bit vectors encoded by blocks. It consistsof two parts:

-   -   The first part is an array which is indexed by the level-k        subregions. For each subregion at level k, it contains the        length of the compressed hit vector. This is relevant for those        outgoing road segments of nodes in the respective subregion for        which the bit vector is encoded by blocks.    -   The second part is a two-dimensional array indexed by (1) the        bit position in the uncompressed bit vector and (2) the level-k        subregion. The array entries specify the bit position in the        compressed bit vector for the given bit position in the        uncompressed bit string read by blocks.

Note that only the first part is held in memory; the second part is onlyused on demand during decoding because it is large. Currently, theregion remap table is only stored at the global-level side-file (k=0).

Initiating a Route Query

The decoder is used to accelerate the route search from a departureposition to a set of destination nodes. (An example where thedestination consists of more than one node is when an entire roadstretch is used as destination.) The destination nodes define a set ofone or more target regions.

Note that a target region is a sequence of region IDs, one for eachpartitioning level, starting at level 0. At the beginning of each newsearch, the set of target regions is built up by clearing the previoustarget region set and passing the new destination nodes to the decoder.The decoder will determine a list of target regions without duplicates.The mechanism for finding the region of a given node is the same asduring the search; see below for details.

Scanning a Node During Route Search

The remaining discussion assumes that a set of target regions has beenset. A feature of the decoder is a function which, given a node ID ofthe road network, returns a bit array (the bit vectors for this node andthe given target regions) which is indexed over the road segmentsleaving this node. The ordering of the nodes and the road segments at anode is defined by the map. Whenever a bit value is zero, this meansthat the corresponding road segment can be ignored during the search.(This usually leads to a considerable reduction of the search space andthus the running time for the search.)

For a small number of nodes, neither region information nor bit vectordata is stored in the side-files. For these nodes, the decoder returns abit string in which all bits are 1. (This will prevent the route searchfrom skipping any road segment at this node.) The decoder has a Booleanquery function which says whether this is the case for a given node.Moreover, there is a Boolean query function which says whether a givennode is located in one of the previously fixed target regions. The bitvectors returned by the decoder for a node in a target region are againbit strings in which all hits are 1. These Boolean query functions areused for optimizations in the route search.

According to the side-file format, the bit vector data for a given nodeis decoded in several steps. In each side-file, the region and bitvector information is organized in so-called pages. The number of nodesper page is a fixed power of 2 (e.g. 16) and identical for eachside-file of a side-file set. This means that, for a given node ID, thepage index of a bit vector page can be computed by a simple bit-shift.Information for the nodes is stored consecutively by node ID.

Finding the Page Offset for a Given Node

For each side-file, the average number of bytes per page is stored inthe header of the side-file. It is used to approximate the byte offsetof the page by multiplying the page index with the average size.

A correction term is stored in a table indexed by the page index. Thistable is stored in a separate section of the side-file. When a page isqueried, the correction term is looked up in the table and added to theapproximate page offset, giving the position of the page in theside-file.

Decoding A Page

Caching

When a page is queried for the first time, the bit vector strings forthe nodes in the page are decoded (with respect to the fixed targetregion set) and cached. The next time data is queried for a node fromthe same page, the cached data can be used without any side-file access.A special marker bit in the decoded bit vector bit string is used toremember whether the node is a no-information node.

Page Code

For each page, a so-called page code bit specifies whether all nodes inthe page have the same region ID. The page code contains one bit perlevel, but all bits are stored as a common Huffman symbol at thebeginning of the page in the level-0 side-file only.

Decoding Outgoing Road Segment Counts

As mentioned above, each page contains information for a fixed number ofnodes. This number of nodes is stored in the header of each side-file.At the beginning of a page (or after the page code, for level 0), thepage lists the number of outgoing road segments for each node in thepage. Whenever the number of outgoing road segments is zero, this meansthat no information at all is stored for the corresponding node. Whilethe page is decoded, the numbers are stored in a temporary array.

Decoding Regions

The road segment counts section is followed by the regions section. Theregion of a node is given by a sequence of region IDs, one at eachlevel. The region ID of a particular level is stored in thecorresponding side-file. The decoder reads the regions at all levels forall nodes in the page. When no information is stored for a node (i.e.the road segment count of the node is zero), the region information isleft empty. The decoder reads the region ID sequence for the first nodewhich has a road segment count greater than zero. If the page code at agiven level specifies that all region IDs are the same at that level,then at that level the same region ID is set for all nodes. Otherwise,the region IDs at the corresponding levels are read for all nodes ofpositive road segment count. At the end of this process, the decoder hasfilled a table with the complete region ID sequences for all nodes ofthe page (where some sequences may be empty).

Decoding Bit Vectors

Finding the Set of Relevant Bit Positions

For a given node and target region, a particular bit at a particularlevel determines the value of the bit vector bits for the road segmentsleaving this node. When there is more than one target region, theresulting bits are ORed together. For each node, the decoder computesthe set of relevant bit positions. The set of relevant bit positions isthe same for each outgoing road segment at that node. It only depends onthe region of the node and the set of target regions. If there is justone target region, there will be only one relevant hit position at onelevel; in other words, information stored at the other levels can beignored for this node. In the case of more than one target region, someof the relevant bit positions may coincide, so there are always at mostas many relevant bit positions as there are target regions. In thefollowing, we shall discuss how the decoder determines the relevant bitposition for one target region. For more than one target region, therelevant bit positions are found in the same way and combined into aset.

When no neighbour regions are defined, there is one bit vector bit (peroutgoing road segment) for each target region at each level. (Forsimplicity, we neglect the fact that no bit is stored for the region IDof the node itself.) The relevant bit is at the first level, counting upfrom level 0, at which the region ID of the node differs from the regionID of the target region. For example, if the region ID of the node atthe global level is equal to the target region ID at the global, but thetwo region IDs are different at level 1, then the relevant bit positionis at level 1, and it equals the target region ID. It is a bit positionin the uncompressed bit vector string at that level; this stringcontains one bit for each possible target region ID. The region remaptable is used to transform this position into a position in thecompressed bit vector string, the string which is actually encoded atthat level.

When neighbour regions are defined (i.e. regions within the visibilityarea), then the relevant bit is determined at the “finest” level atwhich the target region is a neighbour of the node's region. Taking fourlevels as an example, let the target region ID sequence be (a, b, c, d),and let the node's region ID sequence be (e, f, g, h). If (a, b, c, d)is a neighbour of (e, f, g) as defined in the neighbour lists section,and (a, b) is a neighbour of (e), then the relevant bit is determined by(a, b, c, d) and located at level 2, the level of the (e, f, g) prefixwhich contains (a, b, c, d) as a neighbour. More precisely, the relevanthit position is the index of (a, b, c, d) as a neighbour of region (e,f, g) in the level-2 side-file. The regular bit for region ID h, asexplained in the previous paragraph, is irrelevant in this case. Again,this relevant bit position is with respect to the uncompressed bitvector string. The decoder uses the region remap table to transform itto a bit position in the compressed bit string at level 2. Moreinformation on neighbour lists is contained in the document “Proposalfor enhanced multi-level graph partitioning”.

Decoding the Bitvector Bits

Given the fixed set of target regions, the bit vector for each node inthe page will consist of one bit per outgoing road segment. If the roadsegment count of the node is zero (i.e. the node is a no-informationnode), each bit will be set to 1 without further decoding for that node.If the node is located in one of the target regions, the bit vector willagain be all-1; in this case, encoded data might have to be skipped inorder to decode data for the subsequent nodes.

If the bit vector for the current node is not trivially all-1, thedecoder determines the set of relevant hit positions, as explainedearlier. Each hit position is with respect to a particular level, i.e.the hit is located in a particular side-file. At each level, theside-file contains the complete compressed bit string, but the decoderneeds to extract the bits at the relevant bit positions only. Duringdecoding, unused information is read (skipped), but only if it isfollowed by information which is really needed. Otherwise, the unusedpart of the bit stream is not read at all.

The set of relevant bit positions is grouped according to level. Insteadof decoding the compressed bit string and uncompressing it for readingthe bits at the relevant positions, the relevant positions aretransformed into positions in the compressed bit string. If there arerelevant bits at some level, first the data for preceding nodes isskipped, if appropriate (the decoder remembers how far it has come inthe side-file at each level). When the section for the node in questionis reached in a given side-file, the bit vectors are decoded line byline. For each outgoing road segment, one bit is stored; it is theresult of an OR operation of the decoded bit for all relevant bitpositions. The information for a particular road segment at the currentnode starts with a Huffman symbol which specifies the decoding method.It has one of the following values:

-   -   A symbol which specifies that all bit vector bits for the road        segment at this level are 0 (including all neighbour bits at        this level). No further bits have to be decoded for this road        segment.    -   A symbol which specifies that all hit vector bits for the road        segment at this level are 1 (including all neighbour bits at        this level). No further bits have to be decoded for this road        segment.    -   A symbol which specifies that the bit vector bit string is given        explicitly by blocks. The decoding of the compressed hit vector        bit string by blocks is explained below. The hit vector bit for        the road segment is put into a “history stack” that is built up        during the encoding of the entire page.    -   A symbol which specifies an index into the history stack. At the        given index, the history stack contains the desired bit vector        bit value for the road segment.

A different Huffman tree for the decoding method selector is used,depending on the current size of the history stack. There is a limitvalue in the header of the side-file which specifies the number ofHuffman trees; when the size of the history stack exceeds this value,then the last Huffman tree is reused.

If the method selector symbol specifies that the bit vector stringshould be encoded explicitly, then the decoder reads the compressed bitvector bit string block by block. It collects the bit values at therelevant bit positions (with respect to the compressed bit vectorstring) at this level. The values of the bits are ORed. As soon as theintermediate result of the OR becomes 1, the rest of the bits in allfurther blocks for this road segment can be skipped. The Huffman treeused for decoding each block depends on the number of bits in the block.There is one Huffman tree for the regular block length as specified inthe side-file header. The last block for the road segment may beshorter; depending on its size, an appropriate Huffman tree is used fordecoding. A block of length one is just a bit, which is read directlywithout Huffman decoding.

If the number of blocks is at least 2, then the bit stream generatedfrom the bit vector contains an additional bit which comes before theHuffman symbols for the blocks. Its value specifies whether the entiredecoded string is understood to be the bit-wise negation of the actualvalue. (The purpose of this negation is better Huffman compression.)

Note on Search Methods

The skilled person will appreciate that, although the classical Dijkstraand A* search methods produce a search tree and may thus be calledexamples of a tree search, a general route search rooted at a givennavigable segment may typically produce a directed acyclic graph,constituting a subnetwork of the network in which the search is carriedout, and that for any given navigable segment contained in that directedacyclic graph there will be one or more minimum cost routes between thatsegment and the root of the search. Therefore, when mention is made to asearch tree or a tree search, it will be understood that this conceptcan be generalized to a directed acyclic graph resulting from thesearch.

For example, with time varying functions providing speed values fornavigable segments in the map, there can be more than one minimum costroute between a given navigable segment and the root of the search andas such, such searches use a directed acyclic graph rather than a treesearch.

The invention claimed is:
 1. A method of generating a route across an electronic map using a processor of a computing device, comprising: performing, by the processor, a route search across the electronic map, wherein the electronic map comprises a plurality of navigable segments representing segments of a navigable route in an area covered by the map, wherein the map is divided into a plurality of hierarchical regions belonging to at least a coarser level and a neighbouring finer level such that each navigable segment is categorized into at least one region in each of the coarser and finer levels and wherein anyone region of the coarser level contains a plurality of regions of the finer level; performing, by the processor, in a cost calculation at nodes processed during the route search which represent navigable segments in the electronic map, an assessment of whether navigable segments connected to those nodes are marked, within search acceleration data, as being part of a minimum cost route, and if there are such navigable segments exploring only those navigable segments wherein the search acceleration data indicates that a navigable segment is part of a minimum cost route to a region, the search acceleration data for a region of the finer level being constrained to data that indicates whether a navigable segment within a visibility area of the finer level region is part of a minimum cost route to the region, the visibility area comprising the coarser level region containing the finer level region and any regions determined to be close to the coarser level region; generating, by the processor, a minimum cost route across the electronic map from an origin to a destination based on the route search; and providing, by the processor, at least one of: audible navigation instructions to guide a user along the generated route via an output device and displaying the generated route via a display of the computing device.
 2. The method of claim 1, in which the assessment as to whether regions are close to the coarser level region containing the destination region is based upon a predetermined criterion comprising at least one of: graph-theoretical distance, geographical distance, travel time, fuel consumption, and CO2 emission.
 3. The method of claim 1, further comprising associating a time varying function associated with at least some navigable segments.
 4. The method of claim 1, wherein the time varying function associated with a navigable segment represents an average speed on the navigable segment at a plurality of time intervals.
 5. The method of claim 1, wherein the search acceleration data for each segment is stored as a binary bit-vector.
 6. The method of claim 5, wherein the search acceleration data for each segment comprises bits for each of the coarser and finer levels.
 7. The method of claim 5, wherein calculating the search acceleration data for each segment comprises calculating the bit vector showing the minimum cost route across the network at a plurality of time periods rather than at a single time.
 8. A non-transitory computer-readable storage medium storing instructions that, when executed by a processor of a computing device, causes the computing device to perform a method for generating a route across an electronic map, comprising: performing a route search across the electronic map, wherein the electronic map comprises a plurality of navigable segments representing segments of a navigable route in an area covered by the map, wherein the map is divided into a plurality of hierarchical regions belonging to at least a coarser level and a neighbouring finer level such that each navigable segment is categorized into at least one region in each of the coarser and finer levels and wherein anyone region of the coarser level contains a plurality of regions of the finer level; performing, in a cost calculation at nodes processed during the route search which represent navigable segments in the electronic map, an assessment of whether navigable segments connected to those nodes are marked, within search acceleration data, as being part of a minimum cost route, and if there are such navigable segments exploring only those navigable segments wherein the search acceleration data indicates that a navigable segment is part of a minimum cost route to a region, the search acceleration data for a region of the finer level being constrained to data that indicates whether a navigable segment within a visibility area of the finer level region is part of a minimum cost route to the region, the visibility area comprising the coarser level region containing the finer level region and any regions determined to be close to the coarser level region; generating a minimum cost route across the electronic map from an origin to a destination based on the route search; and providing at least one of: audible navigation instructions to guide a user along the generated route via an output device and displaying the generated route via a display of the computing device.
 9. The computer-readable medium of claim 8, in which the assessment as to whether regions are close to the coarser level region containing the destination region is based upon a predetermined criterion comprising at least one of: graphtheoretical distance, geographical distance, travel time, fuel consumption, and CO2 emission.
 10. The computer-readable medium of claim 8, further comprising associating a time varying function associated with at least some navigable segments.
 11. The computer-readable medium of claim 8, wherein the time varying function associated with a navigable segment represents an average speed on the navigable segment at a plurality of time intervals.
 12. The computer-readable medium of claim 8, wherein the search acceleration data for each segment is stored as a binary bit-vector.
 13. The computer-readable medium of claim 12, wherein the search acceleration data for each segment comprises bits for each of the coarser and finer levels.
 14. The computer-readable medium of claim 12, wherein calculating the search acceleration data for each segment comprises calculating the bit vector showing the minimum cost route across the network at a plurality of time periods rather than at a single time. 